Slashdot Mirror
More On The 2.6 Kernel
Jan Stafford writes points out an article in which
"SearchEnterpriseLinux.com expert Ken Milberg digs under the hood of the upcoming 2.6 Linux kernel and examines the benefits and opportunities it presents for Linux in the enterprise." And Semaphore writes "Linux.com is running a great article on the future of ide-scsi in 2.6. It seems Linus and Joerg Schilling, author of cdrtools disagree on whether the problems are with Linux or the application software. Interesting read.."
ide-scsi is mainly used by cd-burning software such as cdrdao and cdrecord (and their frontends). This works fairly well in the 2.2 and 2.4 kernels. However, it does lack some serious functionality: DMA support. Not having DMA support for ide-scsi means that burning takes up a lot of cpu time and it is very easy to cpu-starve the cd-burning software resulting in a bad burn.
This might have never came up if ide-scsi was properly functioning.. but somewhere along the 2.5 series, it became mostly broken.
Linus's solution? Fix the ide-cd interface to pass ATAPI generic instructions (analogous to SCSI generic) and enable DMA for those devices. This requires userspace software changes in cdrecord and cdrdao's scsilib (they share that code). This enables you to run cdrecord --dev=/dev/hdc and have it work.
ide-scsi in 2.6 remains mostly broken. This is a problem for people who use ide-scsi for devices other than cd-r drives, such as zip drives or IDE tapes. A lot of zip drive and tape software was written only for scsi interfaces. ide-scsi lets people use their cheaper ide components with that software.
Where does this leave us?
1. the kernel should have supported burning to atapi devices directly a long time ago.
2. the cd-r software should certainly support burning to atapi devices now (cvs versions of cdrecord and cdrdao support this).
3. ide-scsi should be fixed, but NO ONE IS SENDING PATCHES.
4. ide-cd works for most people, but is not 100%. It doesn't work with my hardware (even for reading CDs). This makes me go back to 2.4 for CD burning.
What should be done?
1. if you use ide-scsi for things other than cd burning and you want to upgrade to 2.6, take a look at the driver and try to fix it. Submit a patch.
2. upgrade your cd-r software.
3. report ide-cd problems to Jens Axboe and the LKML.
Oh, and the author of cdrtools (cdrecord) just wants to talk SCSI to everything and not care what the device actually is. I'm not quite sure why.
Thats it. End of story. Try ide-cd. Drop ide-scsi.
-molo
Using your sig line to advertise for friends is lame.
A while ago the NTFS guys announced that you can indeed write to NTFS, as long as you don't make any new files and don't extend or shorten the length of any existing ones. Not really full write support, but something.
/dev/sg0).
About the usb mass storage devices etc., I suppose that certain features depend on having a SCSI interface, which is provided for non-SCSI devices by ide-scsi. I didn't realize that they need ide-scsi or a SCSI-like interface, and maybe they don't, but if they need ide-scsi and ide-scsi is broken, then people are in trouble. The reason I say that they might not need ide-scsi is that there apparently was an older SCSI interface that used bus/dev/lun addressing (Ex.: 0/1/0) and newer interfaces have been created. Linus wants to keep in the Unix spirit and just use device files (Ex.:
No, it didn't. At least not in the way the article describes. Playing mp3s went quite well when I started using Linux, back in 1999 (Red Hat 6.0, Linux 2.2.5, on a 166 MHz Pentium MMX). The OSS sound drivers weren't great, but they were enough to let an IT manager listen to System Of A Down, even though their debut album from 1998 wasn't quite as good as Toxicity (2001). mp3 folks shouldn't notice much of a difference, despite what TFA says.
ALSA is a good architecture, with a proper API, and should provide better support for the kind of audio musicians need: lower latency, better mixing, MIDI control, and so on. It should be used in conjunction with JACK, the low latency audio server, for that kind of application. Yes, for real multi-media work, ALSA is a lot better than OSS, and probably a necessity, but OSS was quite reliable for just playing or recording sound.
From the fstab manpage:
Instead of giving the device explicitly, one may indicate the (ext2 or xfs) filesystem that is to be mounted by its UUID or volume label (cf. e2label(8) or xfs_admin(8)), writing LABEL= or UUID=, e.g., `LABEL=Boot' or `UUID=3e6be9de-8139-11d1-9106-a43f08d823a6'. This will make the system more robust: adding or removing a SCSI disk changes the disk device name but not the filesystem volume label.
2^5
I didn't realize that they need ide-scsi or a SCSI-like interface, and maybe they don't
They don't need ide-scsi. They (eg, USB storage devices, which might well be flash rom rather than actual disks) need some kind of interface so that they look like something you can put a filesystem on -- and the SCSI protocol (command level) is it. However, the non-IDE devices (USB, 1394, etc) that need it have their own interfaces to the SCSI module, not ide-scsi.
-- Alastair
OSS = Open Sound System (I think) not open source software :-)
OSS was fine for playing music but you couldn't do things like fade from one song to the next so you'd get a "hss" or "pop" between songs if you had a cheap sound card.
I think udev (user space replacement for devfs) is supposed to solve this.
It already runs great on my laptop _and_ my webserver. As long as I stay away from decidedly unstable things (preempt, swsusp, intermezzo) it works.
Some say it's already more stable than 2.4 is.
Don't thank God, thank a doctor!
Supposedly it will also allow dalutong to call his usb devices "camera" and "external_drive" (or whatever he wants). Very cool stuff.
This chap seems to have completely missed the new and much improved support for ACPI. This is a significant feature addition for linux on laptops. APM does leave a lot to be desired.