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@xxxxxx, 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.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/