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
