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

[Tom Gundersen]

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).

> As nobody from the linux kernel folks did ever contact me related to the sg
> driver, it is obvious that not supporting sg is a bug.

Just to clarify: the kernel, and Arch, supports the sg driver just
fine. However, it is not automatically loaded by udev, so people (or
packages) would have to force-load it.

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

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

-t

[0]: <https://lwn.net/Articles/96547/>
[1]: <https://lwn.net/Articles/174469/>
[2]: "After all that SG_IO and cdrecord talk, I decided to brush off
the bsg driver I wrote some time ago."