cd burning: kernel / userspace?

cd burning: kernel / userspace?

[Alan Jenkins]

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

Re: cd burning: kernel / userspace?

[Wakko Warner]

> 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.

> 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 =)

-- 
 Lab tests show that use of micro$oft causes cancer in lab animals

Re: cd burning: kernel / userspace?

[Valdis.Kletnieks]

[-- Attachment #1: Type: text/plain, Size: 815 bytes --]

On Tue, 10 Aug 2004 10:51:30 BST, Alan Jenkins said:

> 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..)

[-- Attachment #2: Type: application/pgp-signature, Size: 226 bytes --]

Re: cd burning: kernel / userspace?

[Alan Jenkins]

>>Some good awkward questions there :). 
>>    
>>
>
>Yup =)
>
>  
>
>>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.
>
>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.

>>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.
>
>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.

Re: cd burning: kernel / userspace?

[Wakko Warner]

Please keep me CC

> 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.

> 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.

> 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.

> 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)
 
> 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)

-- 
 Lab tests show that use of micro$oft causes cancer in lab animals

Re: cd burning: kernel / userspace?

[Alan Jenkins]

Wakko Warner wrote:

>Please keep me CC
>
>  
>
>>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.
>
>  
>
>>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.
>
>  
>
>>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.
>
>  
>
>>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)
> 
>  
>
>>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)
>
>  
>
Sorry, I'm not very good at this list / person CC stuff.  I sent a reply 
to Valdis.Kletnieks@vt.edu, 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.

Re: cd burning: kernel / userspace?

[Wakko Warner]

> Sorry, I'm not very good at this list / person CC stuff.  I sent a reply 
> to Valdis.Kletnieks@vt.edu, 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.

-- 
 Lab tests show that use of micro$oft causes cancer in lab animals

Re: cd burning: kernel / userspace?

[Alan Jenkins]

Wakko Warner wrote:

>>Sorry, I'm not very good at this list / person CC stuff.  I sent a reply 
>>to Valdis.Kletnieks@vt.edu, 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.
>
>  
>
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".

Re: cd burning: kernel / userspace?

[Sergey Vlasov]

[-- Attachment #1: Type: text/plain, Size: 841 bytes --]

On Wed, 11 Aug 2004 20:12:18 -0400 Wakko Warner wrote:

> > 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.

http://www.serice.net/shunt/ can arrange this.

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: cd burning: kernel / userspace?

[Kevin Fox]

Why not use an interface similar to tapes? Have different devices for
different modes of operation?

On Tue, 2004-08-10 at 15:05, Wakko Warner wrote:
> > 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.
> 
> > 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 =)

Re: cd burning: kernel / userspace?

[Wakko Warner]

> 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?  

-- 
 Lab tests show that use of micro$oft causes cancer in lab animals

Re: cd burning: kernel / userspace?

[Pavel Machek]

Hi!

> 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
-- 
People were complaining that M$ turns users into beta-testers...
...jr ghea gurz vagb qrirybcref, naq gurl frrz gb yvxr vg gung jnl!

Re: cd burning: kernel / userspace?

[David Lang]

On Thu, 12 Aug 2004, Wakko Warner wrote:

> Date: Thu, 12 Aug 2004 20:13:02 -0400
> From: Wakko Warner <wakko@animx.eu.org>
> To: Kevin Fox <Kevin.Fox@pnl.gov>
> Cc: Alan Jenkins <sourcejedi@phonecoop.coop>, linux-kernel@vger.kernel.org
> Subject: Re: cd burning: kernel / userspace?
> 
>> 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

-- 
"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