[arch-general] [cdrecord] Problems with original cdrecord on latest linux kernel
Joerg.Schilling at fokus.fraunhofer.de
Mon Jun 11 05:55:11 EDT 2012
Tom Gundersen <teg at jklm.no> wrote:
> On Sun, Jun 10, 2012 at 12:06 PM, Joerg Schilling
> <Joerg.Schilling at fokus.fraunhofer.de> 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 . Notice that the motivation for this stuff seems to
> be cdrecord, so it is very strange that this has not been brought
> to your attention before.
Thank you for undxerstanding the problem!
> : <https://lwn.net/Articles/96547/>
This is just code and absolutely no documentation :-(
> : <https://lwn.net/Articles/174469/>
> : "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
- 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.
EMail:joerg at schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin
js at cs.tu-berlin.de (uni)
joerg.schilling at fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/
URL: http://cdrecord.berlios.de/private/ ftp://ftp.berlios.de/pub/schily
More information about the arch-general