cd burning: kernel / userspace?
I've followed the latest cdrecord "discussion" on the list, and I can't see why you have to use a userspace program which talks SCSI in order to burn a cd.
The current Mount Rainer allows you to treat a MR formatted CD-RW as a big floppy disk - to read and write to /dev/cdrecorder just like /dev/floppy. The packet writing patch takes a different approach - using a separate device which is bound to the cdrecorder device, but AFAIK this is a temporary measure, and the ultimate goal is make this work the same way - the way the user would expect:
1. Insert a recordable media (e.g. cdrw).
2. Perform any necessary formatting (e.g. cdmrw -d /dev/cdrecorder -f full)
3. Access cdrecorder device (e.g. mount /dev/cdrecorder -tudf -onoatime /mnt/cdrecorder)
Why can't a similar method be used for DAO writing? Packet writing and Mount Rainer support belongs in the kernel - why not normal cd burning? On modern "burnproof" hardware, it should be possible to use dd to write your disk image to the cdrecorder device. I'm guessing that this just isn't as interesting, especially with userspace programs available to do the job.
Unfortunately I'm no kernel hacker, so I have no idea whether this is practical, and if so how much work would be involved. I have plenty of time to investigate the idea, and upgrade myself from a mere C programmer. Any advice would be appreciated.
Alan Jenkins
Quoted 3 lines
I've followed the latest cdrecord "discussion" on the list, and I can't see why you have to use a userspace program which talks SCSI in order to burn a cd.
I agree.
Quoted 6 lines
Why can't a similar method be used for DAO writing? Packet writing and Mount Rainer support belongs in the kernel - why not normal cd burning? On modern "burnproof" hardware, it should be possible to use dd to write your disk image to the cdrecorder device. I'm guessing that this just isn't as interesting, especially with userspace programs available to do the job.
Disclamer: I'm not a kernel hacker. Just looking at things on how they appear to me...
I have thought about this myself. Using CDR/RW with the UDF format would be simply packet writing. This is already supported with CDRWs.
However, I usually burn ISO instead of UDF. How should these instances be supported:
1) DAO (ISO image burned)
2) TAO single session with or without fixation. I have burned audio disks like this before where I would leave off the fixate option and keep burning, each track is closed.
3) TAO multi session leaving disk open
4) TAO multi session closing disk (probably similar if not the same as 2)
5) blanking a CDRW (fast and/or slow)
Maybe something along the lines of IOCTLs that do these? Wouldn't it seem silly to:
cdrwcontrol DAO speed=40 burnproof ....
dd if=my.iso of=/dev/scd0 (sorry, I'm a scsi guy =)
or cdrwcontrol TAO speed=40 ...
dd ..
cdrwcontrol fixate
Ok, enough rambling, I think the idea is out =)
Signature · 1 line
Lab tests show that use of micro$oft causes cancer in lab animals
A message that is not in the archive (sent off-list or not yet received): [email protected]
A message that is not in the archive (sent off-list or not yet received): [email protected]
Quoted 19 lines
Quoted 4 lines
Some good awkward questions there :).
Yup =)
Quoted 3 lines
I agree that cdrwcontrol/dd seems silly. I think you would still want to use a commandline tool like cdrecord.
I dunno, with all the talk about the dev=x,y,z stuff. I'm kinda used to it, but why the hell should I have to -scanbus everytime I decide to use a usb cdrw/dvdrw? Even using /dev, it's still interesting since I don't use udev right now. The way that 2.6 does things is rather nice. I wish I could do that on 2.4 with my usb hard drive.
Quoted 5 lines
back to the point. A cdrwcontrol/dd script wouldn't be so bad. I know how they hate things to be in the kernel, but somethings just don't work well in user space
A script would be cool, but dd doesn't do the memory locking and real time priority stuff. I don't know how important this is - how old your hardware would have to be for you to get "coasters" (buffer underun) without it.
Quoted 10 lines
Quoted 3 lines
I need to get to know the technical details better - I understand the instances you listed from the users point of view, but not from the point of view of what gets written to the disk and how.
I had ideas about that... If you're burning one session, it would be easy to have the driver prepare the disk, count the amount of data and once the device is closed, it can do the fixate. Userspace is freed up at this point and it can optionally eject the disk. Just depending on the options presented.
Quoted 7 lines
It would get a bit cumbersom to do data/audio (or just audio) if you don't do dao. Maybe it would be better to have a cdrwtool that once it sets up the ioctls, it can read a stream (stdin or a file) and basically be cdrecord. However, it won't have to drive the cdrw.
Theres an option in cdrecord to fixate an arbitrary disk (one without a TOC for whatever reason), and one not to fixate the disk you're writing, so it looks like fixation could and should be done on demand using an ioctl. You'd also need ioctls to deal with multiple sessions.
I think most people would want a cdrwtool that basically pretends to be cdrecord (in some ways ;), because thats the most intuitive way to do it - even if you can do everything you want to with cdrwtool for the ioctls and dd for the data.
I've definitely underestimated the problems with my idea, and I can't see any tangible benefits which couldn't be obtained by hacking cdrecord. Idealistically, its the right thing to do - but in practice its unessecary, I'm not up to the job, and its not attractive enough for someone to pick up. After packet writing is seamlessly merged into the uniform cdrom driver it might start looking more important, and I might have learnt enough to at least implement a proof of concept. I'm still interested in hashing out more details and potential benefits.
Please keep me CC
Quoted 4 lines
A script would be cool, but dd doesn't do the memory locking and real time priority stuff. I don't know how important this is - how old your hardware would have to be for you to get "coasters" (buffer underun) without it.
Agreed, however, I was attempting to make a point by saying dd.
Quoted 4 lines
Theres an option in cdrecord to fixate an arbitrary disk (one without a TOC for whatever reason), and one not to fixate the disk you're writing, so it looks like fixation could and should be done on demand using an ioctl. You'd also need ioctls to deal with multiple sessions.
Already thought of this. But how to deal with it, I don't know.
Quoted 4 lines
I think most people would want a cdrwtool that basically pretends to be cdrecord (in some ways ;), because thats the most intuitive way to do it
- even if you can do everything you want to with cdrwtool for the ioctls and dd for the data.
That did come to mind, as long as I don't have to use dev=x,y,z (joerg you
listening? Another user steps up to say he hates it =) heheh.
Quoted 2 lines
I've definitely underestimated the problems with my idea, and I can't see any tangible benefits which couldn't be obtained by hacking
I can, like someone else specified. Unlike windows, linux users can put whatever filesystem (or just plain data) on a cd they choose.
They wanted to specify their cdrw to send stuff directly to it and change cds. Something like this (so long as the driver supports it too):
cdrwtool /dev/scd0 -ejectonclose -fixateonclose
note could possibly do -dao with a fixed size. also, I don't know dump's options so I'm improvising
dump -D /dev/scd0 -B 700MB /home
When dump fills 700mb, it will close and await the user. Since the driver was told to fixate and eject on close, the cd comes out ready. I understand buffer underruns here and for starters, underruns aren't part of this picture, it can come later (ie after proof of concept)
Quoted 6 lines
cdrecord. Idealistically, its the right thing to do - but in practice its unessecary, I'm not up to the job, and its not attractive enough for someone to pick up. After packet writing is seamlessly merged into the uniform cdrom driver it might start looking more important, and I might have learnt enough to at least implement a proof of concept. I'm still interested in hashing out more details and potential benefits.
Frankly, I have found that growisofs is awkward to use. I could hack it to be better suited for what I wanted to do (I can't pipe data into it. I used to do mkisofs on one machine, send the data over the network and burn at the same time.) However, it's not as bad as dev=x,y,z
For me, if this were implemented in kernel, I could do this:
nail:~> mkisofs -r -no-pad /80g/debian/x/vol200 | \
ssh vegeta 'cat > /dev/scd0'
(nail is a disk server, vegeta is the box with the burner on /dev/scd0, that's my current setup)
Signature · 1 line
Lab tests show that use of micro$oft causes cancer in lab animals
Quoted 62 lines · Wakko Warner
Please keep me CC
Quoted 3 lines
A script would be cool, but dd doesn't do the memory locking and real time priority stuff. I don't know how important this is - how old your hardware would have to be for you to get "coasters" (buffer underun) without it.
Agreed, however, I was attempting to make a point by saying dd.
Quoted 3 lines
Theres an option in cdrecord to fixate an arbitrary disk (one without a TOC for whatever reason), and one not to fixate the disk you're writing, so it looks like fixation could and should be done on demand using an ioctl. You'd also need ioctls to deal with multiple sessions.
Already thought of this. But how to deal with it, I don't know.
Quoted 5 lines
I think most people would want a cdrwtool that basically pretends to be cdrecord (in some ways ;), because thats the most intuitive way to do it
- even if you can do everything you want to with cdrwtool for the ioctls
and dd for the data.That did come to mind, as long as I don't have to use dev=x,y,z (joerg you
listening? Another user steps up to say he hates it =) heheh.Quoted 3 lines
I've definitely underestimated the problems with my idea, and I can't see any tangible benefits which couldn't be obtained by hacking
I can, like someone else specified. Unlike windows, linux users can put whatever filesystem (or just plain data) on a cd they choose.
They wanted to specify their cdrw to send stuff directly to it and change cds. Something like this (so long as the driver supports it too):
cdrwtool
/dev/scd0-ejectonclose -fixateonclose
note could possibly do -dao with a fixed size. also, I don't know dump's options so I'm improvising
dump -D/dev/scd0-B 700MB /homeWhen dump fills 700mb, it will close and await the user. Since the driver was told to fixate and eject on close, the cd comes out ready. I understand buffer underruns here and for starters, underruns aren't part of this picture, it can come later (ie after proof of concept)
Quoted 3 lines
cdrecord. Idealistically, its the right thing to do - but in practice its unessecary, I'm not up to the job, and its not attractive enough for someone to pick up. After packet writing is seamlessly merged into the uniform cdrom driver it might start looking more important, and I might have learnt enough to at least implement a proof of concept. I'm still interested in hashing out more details and potential benefits.
Frankly, I have found that growisofs is awkward to use. I could hack it to be better suited for what I wanted to do (I can't pipe data into it. I used to do mkisofs on one machine, send the data over the network and burn at the same time.) However, it's not as bad as dev=x,y,z
Quoted 9 lines
For me, if this were implemented in kernel, I could do this:
nail:~> mkisofs -r -no-pad /80g/debian/x/vol200 | \
ssh vegeta 'cat >/dev/scd0'(nail is a disk server, vegeta is the box with the burner on
/dev/scd0, that's my current setup)
Sorry, I'm not very good at this list / person CC stuff. I sent a reply to [email protected], but forgot to CC to list. Contents as follows:
I'm not sure this is necessary. Can't you just do:
# dump -0 -B 700000 -u -z3 /home -f -| cdrecord /dev/hdb -
dump and cdrecord allow you to use "-" as a filename to indicate that output shoud be written to stdout and input should be read from stdin respectively.
Quoted 10 lines
Sorry, I'm not very good at this list / person CC stuff. I sent a reply to [email protected], but forgot to CC to list. Contents as follows:
I'm not sure this is necessary. Can't you just do:
# dump -0 -B 700000 -u -z3 /home -f -| cdrecord /dev/hdb -dump and cdrecord allow you to use "-" as a filename to indicate that output shoud be written to stdout and input should be read from stdin respectively.
Yes, but if I was to understand it right, dump will close/reopen at "700000" (whatever that is, 700000kb?). That won't work with cdrecord since it's expecting a single input stream, not many seperated by a pause. I'd consider it more like using tar with the multiple tape option. When it is finished writing to a tape, it'll wait for the user to physically change tapes and start writing at the beginning of the new tape.
Signature · 1 line
Lab tests show that use of micro$oft causes cancer in lab animals
Quoted 10 lines · Wakko Warner
Quoted 9 lines
Sorry, I'm not very good at this list / person CC stuff. I sent a reply to [email protected], but forgot to CC to list. Contents as follows:
I'm not sure this is necessary. Can't you just do:
# dump -0 -B 700000 -u -z3 /home -f -| cdrecord /dev/hdb -dump and cdrecord allow you to use "-" as a filename to indicate that output shoud be written to stdout and input should be read from stdin respectively.
Quoted 9 lines
Yes, but if I was to understand it right, dump will close/reopen at "700000" (whatever that is, 700000kb?). That won't work with cdrecord since it's expecting a single input stream, not many seperated by a pause. I'd consider it more like using tar with the multiple tape option. When it is finished writing to a tape, it'll wait for the user to physically change tapes and start writing at the beginning of the new tape.
I get it now. BTW, if dump can determine when the end of the media is reached it will close / reopen automatically, so it might also be possible to drop the -B option and make full use of media of different sizes (you can backup more data to an 80 minute CDR, less to a "business card" format one). You couldn't do that with "playing double-buffering games using -F to switch around".
Quoted 8 lines · On Wed, 11 Aug 2004 20:12:18 -0400 Wakko Warner wrote:
Quoted 7 lines
I'm not sure this is necessary. Can't you just do:
# dump -0 -B 700000 -u -z3 /home -f -| cdrecord /dev/hdb -dump and cdrecord allow you to use "-" as a filename to indicate that output shoud be written to stdout and input should be read from stdin respectively.
Quoted 6 lines
Yes, but if I was to understand it right, dump will close/reopen at "700000" (whatever that is, 700000kb?). That won't work with cdrecord since it's expecting a single input stream, not many seperated by a pause. I'd consider it more like using tar with the multiple tape option. When it is finished writing to a tape, it'll wait for the user to physically change tapes and start writing at the beginning of the new tape.
http://www.serice.net/shunt/ can arrange this.
Why not use an interface similar to tapes? Have different devices for different modes of operation?
Quoted 40 lines · Wakko Warner
Quoted 3 lines
I've followed the latest cdrecord "discussion" on the list, and I can't see why you have to use a userspace program which talks SCSI in order to burn a cd.
I agree.
Quoted 6 lines
Why can't a similar method be used for DAO writing? Packet writing and Mount Rainer support belongs in the kernel - why not normal cd burning? On modern "burnproof" hardware, it should be possible to use dd to write your disk image to the cdrecorder device. I'm guessing that this just isn't as interesting, especially with userspace programs available to do the job.
Disclamer: I'm not a kernel hacker. Just looking at things on how they appear to me...
I have thought about this myself. Using CDR/RW with the UDF format would be simply packet writing. This is already supported with CDRWs.
However, I usually burn ISO instead of UDF. How should these instances be supported:
1) DAO (ISO image burned)
2) TAO single session with or without fixation. I have burned audio disks like this before where I would leave off the fixate option and keep burning, each track is closed.
3) TAO multi session leaving disk open
4) TAO multi session closing disk (probably similar if not the same as 2)
5) blanking a CDRW (fast and/or slow)Maybe something along the lines of IOCTLs that do these? Wouldn't it seem silly to:
cdrwcontrol DAO speed=40 burnproof ....
dd if=my.iso of=/dev/scd0 (sorry, I'm a scsi guy =)or cdrwcontrol TAO speed=40 ...
dd ..
cdrwcontrol fixateOk, enough rambling, I think the idea is out =)
Quoted 2 lines
Why not use an interface similar to tapes? Have different devices for different modes of operation?
IIRC, tapes use 2 devices. A rewind on close and a norewind on close. How many devices would there be for the various cd burning?
Signature · 1 line
Lab tests show that use of micro$oft causes cancer in lab animals
Quoted 11 lines · Wakko Warner
Date: Thu, 12 Aug 2004 20:13:02 -0400
From: Wakko Warner <[email protected]>
To: Kevin Fox <[email protected]>
Cc: Alan Jenkins <[email protected]>, [email protected]
Subject: Re: cd burning: kernel / userspace?Quoted 2 lines
Why not use an interface similar to tapes? Have different devices for different modes of operation?
IIRC, tapes use 2 devices. A rewind on close and a norewind on close. How many devices would there be for the various cd burning?
insert track gap on close (track-at-a-time) fixate disk on close (disk-at-a-time or final track)
I don't know if it's worth trying for a 'do nothing on close' since that by definition leaves garbage at the close point so what other modes are needed?
David Lang
Signature · 3 lines
"Debugging is twice as hard as writing the code in the first place. Therefore, if you write the code as cleverly as possible, you are, by definition, not smart enough to debug it." - Brian W. Kernighan
Quoted 6 lines · Alan Jenkins
Why can't a similar method be used for DAO writing? Packet writing and Mount Rainer support belongs in the kernel - why not normal cd burning? On modern "burnproof" hardware, it should be possible to use dd to write your disk image to the cdrecorder device. I'm guessing that this just isn't as interesting, especially with userspace programs available to do the job.
Even less "interesting", but what *I*'d like to be able to do is:
# dump -0 -B 700000 -f /dev/hdb -u -z3 /home
and then just swap to the next CD/RW after -B blocks...
Dumping to a 700M temp file and then cdrecord'ing the temp file really gets old after 15 or 20 CD's (and even playing double-buffering games using -F to switch around isn't all it's cracked up to be..)
Hi!
Quoted 6 lines
Why can't a similar method be used for DAO writing? Packet writing and Mount Rainer support belongs in the kernel - why not normal cd burning? On modern "burnproof" hardware, it should be possible to use dd to write your disk image to the cdrecorder device. I'm guessing that this just isn't as interesting, especially with userspace programs available to do the job.
It would certainly be nice... Character device + some ioctls should do the trick. Someone simply needs to write implement it and see if it ends up simple addition or ugly hack.
Pavel
Signature · 2 lines
People were complaining that M$ turns users into beta-testers... ...jr ghea gurz vagb qrirybcref, naq gurl frrz gb yvxr vg gung jnl!