Learn about Linux
Download Linux
Get Linux helpSpecial Offers
Feature: Linux
Linux 2.6 and the ide-scsi module
Share
Print
Comments
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.As far as the lack of a maintainer for ide-scsi, Linus told me: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.
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.
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
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
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.
-FP
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?
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.
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 AMRe:You do not need ise-scsi a 2.6 anymore burning
Posted by: Administrator on December 10, 2003 09:24 PMYou do not need ise-scsi a 2.6 anymore burning cd
Posted by: Administrator on December 10, 2003 02:28 AMA 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 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.)
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
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.
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.
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
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 PMlibdvdread: 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)
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#