> If there is a simple way to get the mapping between the sg and sr > devices that would be great and almost solve the problems, but I > cannot discover a such thing in the kernel.
You can go trying to match bus values but we have SG_IO on /dev/sr. This is an old known problem with /dev/sg, and it is one reason Jens and co fixed it with the SG_IO interface. > - hald is using O_EXCL already, as wodim does, and this seems to work > well as long as they are acting on the same virtual devices. You might want to try hal polling the master while burning on the slave and vice versa that also used to cause some systems problems. > - of course the hardware does not handle concurent requests, it is > designed that way. It is burden of kernel to canalize the access and > deal with concurrency issues. Obviously the kernel can and shall not It's the job of the kernel to serialize requests coming in and it does that for you both with SCSI and even old IDE. If you ask it to do something stupid then that becomes the desktops problem. > do all the work but at least the basic safety mechanisms must work > reliably and currently they don't. The kernel does not have sufficient information to handle /dev/sg locking by itself. That is one reason /dev/sg is a privileged interface. It's designed to let you do anything however crazy you like, as root. If you do something stupid it breaks. The whole point of /dev/sg is that you can do anything with it. You shouldn't be using /dev/sg for normal CD burning applications on 2.6. For sane systems use the SG_IO interface on the proper device file. That also fixes the need for setuid access and the like except when issuing "dangerous" commands. Christoph is wrong about one point, the hardware isn't broken, The IDE bus is merely badly designed in this area. HAL breaks systems, it causes some laptops to burn power and on a few boxes kills your disk performance. It'll also stop a few boxes reading video-cd disks. Most of that appears to be HAL problems or indirectly through problems in the locking scheme chosen (O_EXCL not fcntl locks). The desktop user space should really know what it is doing with the CD device if it wants to do things like CD burning. If the serial port people could get this right in 1977 then there is no excuse fo the CD using people not getting it right in 2007 Alan - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
