Tom Gundersen <teg@xxxxxxx> wrote: > On Sun, Jun 10, 2012 at 12:06 PM, Joerg Schilling > <Joerg.Schilling@xxxxxxxxxxxxxxxxxxx> wrote: > > Why should someone call an important driver "legacy"? > > I assume it is because it has some problems, and has been replaced by > something else. But you'd have to take it up with the udev maintainer, > as he is the one who made the change, or the kernel maintainer to find > out more about his reasons for introducing bsg. I'm just letting you > know about the issue (I expect this change will hit most distributions > soon if it has not already). Of course, sg has problems and I talk about them since a long time. Unfortunately, there does not seem to be any interest from the Linux Kernel folks to fix the problems. > > It is bad practice to replace one driver by another just to cause > > incompatibilities instead of enhancing existing software. > > Maybe so, I'm just pointing out what has happened and what we have to > deal with. I don't really know the reasons very well. I would expect that people who like to fix problems in this area first contact me for a list of problems and fix proposals. This software seems to be a result of a change made by one person alone without asking potential users. > > and btw. this supposed sg replacement is undocumented. > > I could not find much about it, but if anyone is interested I found a > few sources [0][1]. Notice that the motivation for this stuff seems to > be cdrecord[2], so it is very strange that this has not been brought > to your attention before. Thank you for undxerstanding the problem! > [0]: <https://lwn.net/Articles/96547/> This is just code and absolutely no documentation :-( > [1]: <https://lwn.net/Articles/174469/> See above... > [2]: "After all that SG_IO and cdrecord talk, I decided to brush off > the bsg driver I wrote some time ago." The problem on Linux is not that we need to replace one driver by another one delivering the same faulty interface just in a slightly modified way that prevents existing software from being able to use it. The real problems with SCSI on Linux are: - Not all devices that talk SCSI are available via the same driver name space. Example: ATAPI via PATA is excluded, ATAPI via SATA is included. - Missing working support for DMA residual counts. - No useful and predictable way to get/set the maximum DMA size for a given device. - The SCSI status code in the Linux SCSI glue layer is stored in a modified form that causes frequent problems with drivers that forget about that fact and cause the Generic SCSI layer to report wrong status codes. - A specific device is accessible via more than one driver and there is no locking between these drivers. Introducing another driver in this list will just cause more problems. - The existence of hostile software like "hald" and similar followups that repeatedly send SCSI commands to many devices. These commands interrupt the CD/DVD/PluRay writing process. This is a result of the fact that the author of hald and it's successorts has no clue on the state model of SCSI devices with changeable media ans is not willing to listen to people who like to help him to understand the background. If you know how SCSI devices work in this area, it is of course possible to avoid the Linux specific problems. As you see, there is plenty of work to do. From what I see, Mr. Axboe did not address a single of the problems in the list with his work. Jörg -- EMail:joerg@xxxxxxxxxxxxxxxxxxxxxxxxxxx (home) Jörg Schilling D-13353 Berlin js@xxxxxxxxxxxxxxx (uni) joerg.schilling@xxxxxxxxxxxxxxxxxxx (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/private/ ftp://ftp.berlios.de/pub/schily
