[arch-general] [cdrecord] Problems with original cdrecord on latest linux kernel

[Joerg Schilling]

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 [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 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