Re: cd burning: kernel / userspace?

From: Alan Jenkins
Date: Wed Aug 11 2004 - 16:49:38 EST


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/