Re: CD DVD drive docs
Hi,
David Niklas wrote:
> I noticed a user who knows much about CD and DVD drives
(Looking around whether anybody else feels addressed)
> I'm curious
> about what books or docs he might recommend to learn about the topic,
> for if things continue as they are, it seems we will run out of people
> with the know-how.
I have written my CD/DVD/BD related last will in
http://libburnia-project.org/browser/libburn/trunk/doc/cookbook.txt
(also part of the libburn source tarball, and actually rather
for giving potential forkers a better chance than cdrkit had).
It refers to drafts of SCSI specs SPC-3 and MMC-5, which were once
available for free. They vanish and re-appear in the web.
(Google "scsi mmc". Look for [PDF]. Where there is one, there are more.
Older versions are of interest, too.)
In worst case one has to pay 30 dollar each for official PDFs of
MMC-5 and SPC-3. The command START/STOP UNIT is documented in
http://libburnia-project.org/browser/libburn/trunk/libburn/sbc.c#L29
so you can save the 30 dollar for SBC-2.
These specs define the protocol of transactions between computer
and DVD drive. If the DVD related program resides in GNU/Linux
userspace, then it uses ioctl(SG_IO) to perform such transactions
via the Linux kernel.
http://www.tldp.org/HOWTO/SCSI-Generic-HOWTO/
libburn's Linux specific OS interface is implemented in
http://libburnia-project.org/browser/libburn/trunk/libburn/sg-linux.c
The source code of dvd+rw-tools is always worth a look when
the own understanding of SCSI does not work as expected.
> > error "No medium found" before the drive LED stops blinking.
> Shouldn't this be reported to the kernel devs as a regression?
There are kernel devs in reach ?
I'd really like to learn why the concurrent performance of
multiple ioctl(SG_IO) on different drives has dropped so sharply,
compared with kernel 2.6.
We have at least two Debian bugs on that topic
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=709971
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=768504
For the first one i can provide a coarse workaround.
The second one would need an option for curbing software read
speed in cdparanoia while keeping hardware read speed high ...
... if my theory about a bottleneck with a single pending
ioctl(SG_IO) is correct. If this ioctl() happens to cause a
long running transaction, then it blocks all others. But it
seems to block longer than really needed.
I want to find and understand the kernel source that
takes care of stuff in the i/o elevator and after the elevator
ride. (At least i could follow SG_IO up to the elevator's
door in kernel 2.6.)
Have a nice day :)
Thomas
Reply to: