lkml.org 
[lkml]   [2004]   [Aug]   [11]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: cd burning: kernel / userspace?
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.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2005-03-22 14:05    [W:0.077 / U:2.616 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site