Linux 2.6 and the ide-scsi module

If you’ve followed Linus Torvalds’ postings on the Linux kernel mailing list (the LKML) for awhile, then you’re aware of the high esteem he has for kernel code written with “good taste.” It seems the highest compliment Linus ever pays to other kernel hackers is to refer to them as having “good taste.” It’s a compliment he has reserved for a very select few: Alan Cox and a handful of others. His disdain for code written in “bad taste” appears to be just as strong as his appreciation of the good. Over the past few months, one particular kernel module has been the center of a mild controversy. On the surface the problem seemed at first to simply be a bug that was exposed in testing of the 2.6 kernel. But it’s proved to be more serious than that: it’s an example of “bad taste.”

So what’s the problem?

The module is ide-scsi, and its function is/has been to provide a “SCSI like” interface for certain non-SCSI devices and applications. Foremost among them, writable CD-Rom drives and the hugely popular cdrecord. As a result, some on the LKML have worried that a broken ide-scsi module is going to mean that those with ATAPI IDE tape drives, or digital cameras, or USB storage devices won’t be able to use them with the new kernel.

In early November, Bill Davidsen responded to a post on the LKML about a problem someone was having with burning a CD. Davidsen said:

There is a problem with ide-scsi in 2.6, and rather than fix it someone
came up with a patch to cdrecord to allow that application to work
properly, and perhaps “better” in some way. Since the problem with
ide-scsi seems to still exist for other applications, you will probably
find you have to work around the problem, by using the -pad option of
cdrecord (thought that was standard now for TAO at least) or reading
using the ide-cd driver.

Torvalds responded to Davidsen’s post by writing:

On 6 Nov 2003, bill davidsen wrote:
>

> There is a problem with ide-scsi in 2.6, and rather than fix it someone
> came up with a patch to cdrecord to allow that application to work
> properly, and perhaps “better” in some way.

Wrong.

The “somebody” strongly felt that ide-scsi was not just ugly but _evil_,
and that the syntax and usage of “cdrecord” was absolutely stupid.

That somebody was me.

ide-scsi has always been broken. You should not use it, and indeed there
was never any good reason for it existing AT ALL. But because of a broken
interface to cdrecord, cdrecord historically only wanted to touch SCSI
devices. Ergo, a silly emulation layer that wasn’t really worth it.

The fact that nobody has bothered to fix ide-scsi seems to be a result of
nobody _wanting_ to really fix it.

So don’t use it. Or if you do use it, send the fixes over.

Linus

The back-and-forth between Davidsen and Torvalds has continued, and as a result more and more of Torvalds disdain for the ide-scsi and cdrecord interface has bubbled to the surface. Torvalds has said, among other things, that:

• “anybody who uses cdrecord has either been confused by the silly SCSI numbering”
• “Some people ended up having to boot with ide-scsi enabled to burn CD’s, but
  then if they wanted to watch DVD’s (on the same drive), they needed to
  boot without it.”
• “the old cdrecord interfaces are an UNBELIEVABLE PILE OF CRAP!”
• “It’s an interface that is based on some random hardware layout mechanism
  that isn’t even TRUE any more, and hasn’t been true for a long time.”
• “It’s bad from a technical standpoint (anybody who names a generic device
  with a flat namespace is just basically clueless), and it’s bad from a
  usability standpoint. It has _zero_ redeeming qualities.”

There’s more, but that’s enough to give you a sense of Torvalds’ unhappiness with the whole approach of both one particular (though very popular) app and the ide-sci module itself.

Linux is the worst

Joerg Schilling, author of cdrtools (which includes cdrecord) has a completely different view. He doesn’t feel the problem is in cdrecord, but in Linux. He wrote:

Sorry, I did have to learn that the Linux kernel developers (and above all their
loudest speaker Linus Torvalds) don’t have the knowledge to discuss
kernel internals 🙁

The more I try to explain them how a decent SCSI transport interface should
look, the more I fail. I never did check a 2.6 Linux kernel and as SuSE
did stop giving away free SuSE distributions to developers more than half a
year ago, it is very unlikely that I will install a newer Linux kernel.

Linux is the worst OS I am aware of if you compare SCSI transport
implementations. Every even year, a new completely disjunct new kernel interface
appears. Non of the new kernel interfaces includes the features that I like to
have and documented since 1995. For this reason, it is not possible to develop
cdrecord on Linux – I use Solaris where I get the needed features.

More on page 2…Should you be worried?

Still, Bill Davidsen warned of coming calamity for all sorts of strange device users, including tape drives and digital cameras. This left me wanting to know where this situation left users with devices currently using ide-scsi when they upgrade to the Linux 2.6 kernel. So I began to ask key players that very question.

I emailed Sebastian Trueg of the K3B project. He assured me that K3B is already working with the 2.6 kernel and that no further changes will be required. As for cdrecord, the underlying tool used by K3B and other projects, it is working too, thanks to a patch submitted by Torvalds.

I also queried SuSE Linux kernel hacker Jens Axboe as to why nobody was stepping up to assume the maintainer’s position for the ide-scsi module. He replied: “There really isn’t a great need for ide-scsi anymore, since burning works without it. So the “market” for it has shrunk to basically nothing. Apparently the remaining people either don’t know it’s broken yet because they haven’t tried 2.6, or noone knowledgable enough to fix it has discovered it.”

Jens did not seem to be overly concerned about the situation. He went on to say ”
My guess is that it will get fixed soonish by some volunteer. If that doesn’t happen, then I might have to do it myself before SUSE ships it. It’s tempting to say it’s conveniently broken right now, as informs people (in a brutal way) that ide-scsi burning is deprecated and should not be used.”

I also emailed Linus with a fist-full of questions on the subject, which he was kind enough to answer.

The first thing Linus did was to point out a fallacy in my understanding of the problem. The problem is not that there is a bug in ide-scsi. Rather it’s:

No, the bug in ide-scsi is that it has no maintainers, and it’s trying to
cross two different subsystems, and it can easily get it wrong.

The “scsi device identification” thing is a separate issue: cdrecord
basically doesn’t want to bother with things like filenames, and instead
it wants to just open a SCSI generic device (preferably one that has _no_
connection to any specific hardware at all), and then it wants to
enumerate devices with “bus+device+lun” numbers.

That’s a cdrecord oddity, nothing more.

As far as the lack of a maintainer for ide-scsi, Linus told me:

Yes. Both I and Jens have tried to fix it for breakage, and apparently my last fix actually made it work again for a lot of people, but basically it doesn’t actually add any real value at that point anyway.

The value it adds seems to be:

– “keep things the same” (ie just to avoid breakage for people who don’t
want to touch their configuration)

– some people apparently use some really odd-ball devices, like IDE tape
drives, and maybe the ide-tape driver is flaky or something, so they
apparently do ide-scsi + the scsi tape driver.

I’m not actually sure about the last one. I’ve not gotten any reports
from people like that. But others claim they exist.

Basically, for the regular IDE-CD read/write, the normal IDE driver should
work. If it doesn’t, it’s a driver bug already, and ide-scsi isn’t likely
to work either 😉

One thing I did have correct was that he dislikes the phony-SCSI and much prefers things be properly named. Torvalds wrote “Absolutely. I actually like the SCSI _command_ set, and that one is used by pretty much everything (ie whether it is electrically SCSI or not, FC, IDE, USB all use the SCSI command set to talk to disks). But I always disliked the notion that some people have that that should make it all be “SCSI”.

Don’t worry, be happy

The bottom line seems to be that since cdrecord has been patched to handle IDE device names as well as the old SCSI naming scheme, and most applications for those devices (like K3B) use cdrecord to access them, there will be only a few broken by the move to 2.6. If and when that happens, someone will step up to fix it.