Learn about Linux
Download Linux
Get Linux helpSpecial Offers
Feature: Linux
Linux 2.6 and the ide-scsi module
By Joe Barr
on
December 09, 2003 (8:00:00 AM)
Share
Print
Comments
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 :-(More on page 2...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.
Comments
on Linux 2.6 and the ide-scsi moduleNote: Comments are owned by the poster. We are not responsible for their content.
Yes. Quoting from a recent post on the LKML:
Can burn CDs and DVD+RWs without IDE-SCSI just fine.
k3b 0.10.2
cdrdao 1.1.8pre2
cdtools 2.01 alpha 19
Funny, I was just ripping ide-scsi the other day with a friend. Besides the issues proposed by this article, there's a huge problem affecting users of IDE devices connected via the USB bus.
I recently purchased a USB 2.0 external enclosure for some of my IDE drives. However, it wasn't until I started playing with it that I realized that ide-scsi was necessary for interoperating with the usb-storage drivers. Forcing a scsi interface on these devices means I lose the ability to tweak IDE settings with hdparm (32-bit I/O, DMA, etc). Has anyone considered this?
-fuzzyping
I recently purchased a USB 2.0 external enclosure for some of my IDE drives. However, it wasn't until I started playing with it that I realized that ide-scsi was necessary for interoperating with the usb-storage drivers. Forcing a scsi interface on these devices means I lose the ability to tweak IDE settings with hdparm (32-bit I/O, DMA, etc). Has anyone considered this?
-fuzzyping
"Forcing a scsi interface on these devices means I lose the ability to tweak IDE settings with hdparm (32-bit I/O, DMA, etc). Has anyone considered this?"
Wouldn't something like "echo using_dma:1 ><nobr> <wbr></nobr>/proc/ide/hdd/settings" also do the trick? I haven't tested this on anything other than internally connected devices (e.g. internal HD's and CD/DVD-ROMs.
No, because it wouldn't be presented in<nobr> <wbr></nobr>/proc as an IDE drive in the first place. Because it uses the SCSI interface, all USB external drives are presented as<nobr> <wbr></nobr>/dev/sd*.
-FP
-FP
ide-scsi goes the other way. It makes IDE devices into pretend SCSI ones.... poorly. You can't hdparm an IDE device that is being handled by ide-scsi, either. You have to understand those enclosures may talk IDE to the drive, but talk USB to the bus. I'm not real sure why the USB developers decided to pretend that USB storage devices are SCSI, though. I have to admit, it's a little odd talking to a USB floppy drive through<nobr> <wbr></nobr>/dev/sda, but luckily, that's my only USB mass storage device, so the number of bad things that can happen are severely limited.
Yes, I know. You've just restated everything I said.
http://www.freebsd.org/cgi/man.cgi?query=burncd&a<nobr>p<wbr></nobr> ropos=0&sektion=0&manpath=FreeBSD+4.9-RELEASE&for<nobr>m<wbr></nobr> at=html
I have burned DVDs fine with the latest k3b using 2.6 test-10, running Slackware 9.1<nobr> <wbr></nobr>/w updates using Swaret. I haven't had a problem<nobr> <wbr></nobr>:D Only a little glitch where I couldn't see the buffer status, but that just might be my setup. The burn was a complete success though. I am using a LiteON 401S currently.
Forgive the Linux Newbie. It was my understanding that cdrecord ans ide-scsi were the only way to go. Now that I see that it is not. What are the otions? What software? Which kernel version are supported...etc?
I allways tought ide-scasi for cdburning was a bit tacky. Glad this isn't needed anymore. Hopefully any of the cd writing howtos will be updated soon.
cdrecord worked great for me. I used it with Plextor SCSI devices. ATAPI sucked in Linux.
As for the syntax, give me a break. I wrote a simple shell script called 'mkcd'. Amazing, eh?
The point of the cdrecord author is extremely valid. He doesn't want to change his code when the Linux kernel guys decide to change the interface, etc. He wants a standard API. That API is SCSI. He wants someone else to deal with all the device BS and simplify it as SCSI. Linus, it seems, wants him to deal with the device issues or for someone to write a nice ide-scsi.
So what is the preferred burning tool now?
As for the syntax, give me a break. I wrote a simple shell script called 'mkcd'. Amazing, eh?
The point of the cdrecord author is extremely valid. He doesn't want to change his code when the Linux kernel guys decide to change the interface, etc. He wants a standard API. That API is SCSI. He wants someone else to deal with all the device BS and simplify it as SCSI. Linus, it seems, wants him to deal with the device issues or for someone to write a nice ide-scsi.
So what is the preferred burning tool now?
cdrecord with the linux atapi patch is the current preferred tool.
SCSI is a shoddy way to interface to non-scsi devices. What we need is a standard interface for devices that are not SCSI that is not a faux-scsi interface. A single interface that is NOT scsi that works for both scsi and ide devices would work as well. Really though, it'd be more fun if cdrecord's functionality were built into the kernel.
SCSI is a shoddy way to interface to non-scsi devices. What we need is a standard interface for devices that are not SCSI that is not a faux-scsi interface. A single interface that is NOT scsi that works for both scsi and ide devices would work as well. Really though, it'd be more fun if cdrecord's functionality were built into the kernel.
Why built into the kernel? Since we already know a functional CD writing method can run quite happily in userspace, I'd just like to see one that understood IDE. Preferably in the form of a lib with a nice simple interface and then we can all write our own utilities, just the way we like them. I'm not holding my breath though.
Surely the ideal is to have as few things as possible in kernel space? That was supposedly the big architectural argument behid udev. Although, at the same time the mouse drivers were moved into the kernel, for no real reason as far as I can see, messing up a lot of people's pointing devices.
Surely the ideal is to have as few things as possible in kernel space? That was supposedly the big architectural argument behid udev. Although, at the same time the mouse drivers were moved into the kernel, for no real reason as far as I can see, messing up a lot of people's pointing devices.
Well its 2007 and this article proves all involved
Posted by: Anonymous Coward on March 09, 2007 11:12 AM
... are fucking idiots. This is exactly why "real" companies use a software PROCESS and all the fucking "hacking" (read negative conotation) is really just all about ego-maniacs who would be kings. Fuck Linux, Fuck CDRTOOLS. I been using Linux since 1998 but I can now see cracks in the "bazzare". Maybe I'll give vista a try - works great at work, maybe Microsoft IS the better choice if this kind of infantile ego-maniac tantrums are going to be the norm. Linus - my 6 year acts more adult than you - too bad it never had the opportunity to GROW-UP!
Re:You do not need ise-scsi a 2.6 anymore burning
Posted by: Administrator on December 10, 2003 09:24 PM
That's what Linus was stating in his comments. You don't have to restate what has already been told. We *CAN* read. As for DVD playback, well that's a good thing. The mem stick should've been working since 2.4.19 at least. That is the first kernel I got my mem stick to work on, simply insmod the usb module for it and viola( the mistake here is done on purpose. I know how to spell voila, since my first language is French ). As for the camera, well, it's a matter of driver in the apps, not the kernel.
You do not need ise-scsi a 2.6 anymore burning cd
Posted by: Administrator on December 10, 2003 02:28 AM
I don't don ise-scsi in kernel 2.6 anymore for burning my cd of dvd anymore.
A lot of problems are solved also the quality of palyback of the dvdwriter for playing dvd was incredible improved.
My usb camera and memory stick is working quit well
A lot of problems are solved also the quality of palyback of the dvdwriter for playing dvd was incredible improved.
My usb camera and memory stick is working quit well
I agree with Linus on this one! I have never quite understood why I should use ide-scsi for an atapi drive - it makes a lot of potential linux users run a mile (I have seen them!)
What about all of the non-CD/DVD devices? I know there are many non-CD/DVD based devices that required the scsi-ide module. A few that come to mind are the 3Ware Escalade driver, certain USB floppy drives, and the USB SanDisk-9 module. Have all of these modules been giving native support?
I know there are many non-CD/DVD based devices that required the scsi-ide module. A few that come to mind are the 3Ware Escalade driver, certain USB floppy drives, and the USB SanDisk-9 module.
Actually, no.. the Escalade has it's own driver already in the kernel since at least sometime in the 2.4 series. It's seen by Linux as an actual SCSI device (ie:<nobr> <wbr></nobr>/dev/sda) and not accessed as some rediculous dev=0,1,0 device.
As far as I know the USB devices also have never been accessed via the scsi-ide interface either (especially since they are USB and not IDE devices.)
What is he really complaining about? The fact that Linux won't create an all encompassing SCSI driver that does everything so the code doesn't have to change? Or is it simply that the Linux SCSI drivers are inadequate in there implementation? All I can tell is he is pissed and opinionated.
I always thought cdrecord sucked. The use of a bogus SCSI addressing system instead of a<nobr> <wbr></nobr>/dev/cdrw or similar link, is a weird thing.
But it's hardly the only weird thing in Unix,Linux, and BSDs. In fact, just about every unix app has its own set of totally unique idioms: make, patch, configure, gzip, tar, vi, emacs, less, awk, grep, sed, tr, dd. Then there are the different flavours of incompatible shells: bash, csh, ksh.
The solution is simple: cdrecord is free software, it works well enough, if you don't like the interface, which I sure didn't, you can change it, or you can just learn to live with it. If it irritates you enough, fork it or patch it. SCSI is irrelevant, the point is burn the damn cd. If the very author of cdrecord doesn't get it, maybe it's time people who aren't sheep thought for themselves, and fixed the uglies. Linus is no dummy. It's ugly for a reason. I have used cdrecord for several years, and I *still* need to do a "man cdrecord" before every time I use it. It's worse even than how awful I find using tar, or patch. (gzcat<nobr> <wbr></nobr>../foo.patch.gz | patch -p1)? Why not "patch<nobr> <wbr></nobr>../foo.patch.gz"?
Warren Postma
But it's hardly the only weird thing in Unix,Linux, and BSDs. In fact, just about every unix app has its own set of totally unique idioms: make, patch, configure, gzip, tar, vi, emacs, less, awk, grep, sed, tr, dd. Then there are the different flavours of incompatible shells: bash, csh, ksh.
The solution is simple: cdrecord is free software, it works well enough, if you don't like the interface, which I sure didn't, you can change it, or you can just learn to live with it. If it irritates you enough, fork it or patch it. SCSI is irrelevant, the point is burn the damn cd. If the very author of cdrecord doesn't get it, maybe it's time people who aren't sheep thought for themselves, and fixed the uglies. Linus is no dummy. It's ugly for a reason. I have used cdrecord for several years, and I *still* need to do a "man cdrecord" before every time I use it. It's worse even than how awful I find using tar, or patch. (gzcat<nobr> <wbr></nobr>../foo.patch.gz | patch -p1)? Why not "patch<nobr> <wbr></nobr>../foo.patch.gz"?
Warren Postma
> (gzcat<nobr> <wbr></nobr>../foo.patch.gz | patch -p1)? Why not "patch<nobr> <wbr></nobr>../foo.patch.gz"?
You *could* use "patch -i<nobr> <wbr></nobr>../foo.patch", provided that foo.patch has already been decompressed.
And the answer to your question lies deep in the Unix philosophy: have small tools that do one thing well, and combine them to achieve composite results. There's really on point in patch's knowing how to deal with gz files. I personally do not use gzipped patches, but rather bzip2ed ones. Someone else might prefer patching directly from the Internet (wget -O- -q http://kernel.org/pub/linux/kernel/v2.4/patch-2.4<nobr>.<wbr></nobr> 23.bz2 | bzcat | patch). You see where I'm going<nobr> <wbr></nobr>;)
Reading ESR's nice book The Art of Unix Programming (readable online at ) might give do you good. Don't get intimidated by the title, it really has little to do with programming details but gives you some ideas of why Unix is what it is today and what facilities have traditionally been available to develop software on it.
You *could* use "patch -i<nobr> <wbr></nobr>../foo.patch", provided that foo.patch has already been decompressed.
And the answer to your question lies deep in the Unix philosophy: have small tools that do one thing well, and combine them to achieve composite results. There's really on point in patch's knowing how to deal with gz files. I personally do not use gzipped patches, but rather bzip2ed ones. Someone else might prefer patching directly from the Internet (wget -O- -q http://kernel.org/pub/linux/kernel/v2.4/patch-2.4<nobr>.<wbr></nobr> 23.bz2 | bzcat | patch). You see where I'm going<nobr> <wbr></nobr>;)
Reading ESR's nice book The Art of Unix Programming (readable online at ) might give do you good. Don't get intimidated by the title, it really has little to do with programming details but gives you some ideas of why Unix is what it is today and what facilities have traditionally been available to develop software on it.
I would like to know which utility it is that "[does] one thing well". They may do something well, but I'm having a hard time thinking of a utility that does just on thing, and doesn't need twelve command line switches just to do one thing.
And if it is necessary to have all of these switches, I would think that you could make them contextual so that incompatible switches can't be entered.
As far as I can tell, the environments that fostered the creation every legacy Unix utility have ceased to exist. Vi, for one, according to its author, was created to make it possible to do editing over EXTREMELY slow (110 baud) connections. Now, the existence of most of these programs is only justified by compatibility with the scripts that were created so that people could actually be productive.
In short, they are small, useful and ubiquitous, so there is no need to stop using them, but don't villify people trying to create something a little more usable. After all, the GUI is the the right tool for the job if you need to point at something and say, "I want THAT." Under other circumstances, latitude and longitude might be better, but the goal remains the same: efficiency.
And if it is necessary to have all of these switches, I would think that you could make them contextual so that incompatible switches can't be entered.
As far as I can tell, the environments that fostered the creation every legacy Unix utility have ceased to exist. Vi, for one, according to its author, was created to make it possible to do editing over EXTREMELY slow (110 baud) connections. Now, the existence of most of these programs is only justified by compatibility with the scripts that were created so that people could actually be productive.
In short, they are small, useful and ubiquitous, so there is no need to stop using them, but don't villify people trying to create something a little more usable. After all, the GUI is the the right tool for the job if you need to point at something and say, "I want THAT." Under other circumstances, latitude and longitude might be better, but the goal remains the same: efficiency.
That's the funny thing. I already know the things ESR talks of, and most times I agree with him. But what I find odd in Unix is that the most common tasks often are never thought of.
What are the two things 99.99% of people do most often do with tar? THey should be the default actions. "tar [tarfilename] [directory]", and "untar [tarfilename]", not "tar jxf [filename.tar.bz2]", and if 99.99% of the time, patch is used as you put it "patch -i ", then "patch " ought to be the default.
Pipes, and all, are good. But must one use pipes merely to do simple tasks? Must one combine two utilities with a pipe just to do the most common case of using each tool? This stems from a wholly non-admirable tendency (in both Unix and other operating systems), which is that it's easier to develop a library of workarounds and kludges than it is to try to improve things. I like most things about Linux and in general, I have learned to like most things about common unix-like command line tools, but I can't deny their ugliness. A few things are really elegantly designed, but most common utilities contain entirely accidental designs.
WPostma
What are the two things 99.99% of people do most often do with tar? THey should be the default actions. "tar [tarfilename] [directory]", and "untar [tarfilename]", not "tar jxf [filename.tar.bz2]", and if 99.99% of the time, patch is used as you put it "patch -i ", then "patch " ought to be the default.
Pipes, and all, are good. But must one use pipes merely to do simple tasks? Must one combine two utilities with a pipe just to do the most common case of using each tool? This stems from a wholly non-admirable tendency (in both Unix and other operating systems), which is that it's easier to develop a library of workarounds and kludges than it is to try to improve things. I like most things about Linux and in general, I have learned to like most things about common unix-like command line tools, but I can't deny their ugliness. A few things are really elegantly designed, but most common utilities contain entirely accidental designs.
WPostma
I hate to have to point this out but have you thought about creating aliases? This way you can set up commands with your own preferred options/pipes and thoroughly confuse anyone else that tries to use your system (:
You have a point about utilities not behaving the way you expect, but in many cases a utilities "erroneous" behavior cannot be changed. The command line is really another example of an interface, and to changinging an interface runs the risk of breaking all the scripts that rely on the existing (possibly POSIX) behavior. Sometimes even fixing a bug would break existing scripts or code.
The only safe bet is to introduce wrapper scripts which are in effect an alternate API, then again once you get used to using the wrapper, you forget how to use the standard tools. Sort of a catch-22
The only safe bet is to introduce wrapper scripts which are in effect an alternate API, then again once you get used to using the wrapper, you forget how to use the standard tools. Sort of a catch-22
So what is the solution for DVD Playback with 2.6?
Posted by: Administrator on December 16, 2003 09:06 PM
Ogle, Xine and mplayer all use libdvdread / libdvdcss. The following errors used to vanish when using ide-scsi:
libdvdread: Can't seek to block 256
libdvdread: Can't open file VIDEO_TS.IFO.
the long description is <A HREF="http://criggie.dyndns.org/linux-dvd/" TITLE="dyndns.org">here</a dyndns.org>:
[...]
Kernel 2.6.x has removed devfs, so links like<nobr> <wbr></nobr>/dev/dvd are not made automatically, and they're not remembered across reboots. You may need to make them another way.
What does this error mean?
libdvdread: Using libdvdcss version 1.2.5 for DVD access
libdvdread: Can't seek to block 256
libdvdread: Can't open file VIDEO_TS.IFO
It means that you aren't using ide-scsi for the
DVD drive. Read and follow this page.
[...]
btw. I do have r/w access to<nobr> <wbr></nobr>/dev/dvd and the symlink it points to (which i can mount to read the content of the dvd)
anyway: What is the standart way of watching dvds with kernel 2.6(-test9)
libdvdread: Can't seek to block 256
libdvdread: Can't open file VIDEO_TS.IFO.
the long description is <A HREF="http://criggie.dyndns.org/linux-dvd/" TITLE="dyndns.org">here</a dyndns.org>:
[...]
Kernel 2.6.x has removed devfs, so links like<nobr> <wbr></nobr>/dev/dvd are not made automatically, and they're not remembered across reboots. You may need to make them another way.
What does this error mean?
libdvdread: Using libdvdcss version 1.2.5 for DVD access
libdvdread: Can't seek to block 256
libdvdread: Can't open file VIDEO_TS.IFO
It means that you aren't using ide-scsi for the
DVD drive. Read and follow this page.
[...]
btw. I do have r/w access to<nobr> <wbr></nobr>/dev/dvd and the symlink it points to (which i can mount to read the content of the dvd)
anyway: What is the standart way of watching dvds with kernel 2.6(-test9)
It's a horrible piece of shit, in badly need of re-writing. The entire cdrtools is an example of how NOT to write C code.
I do not burn CDs on linux because of it.
I do not burn CDs on linux because of it.
what about dvd-writing?
Posted by: Anonymous Coward on December 09, 2003 11:15 PM#