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

Comments

Sound Support

[voss]

Wow it only took 10 years to get reliable sound support into the kernel ;-)

Re:Sound Support

[Spoing]

Wow it only took 10 years to get reliable sound support into the kernel ;-)

That's not insightful, it's funny.

On a serious note, I've used the OSS modules for 5+ years, and it's worked well for me. Alsa is quite nice and I'm glad to see it as the default in the kernel now, though OSS is not unreliable by a long shot.

Re:Sound Support

[MrHanky]

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.

usb-storage and ntfs

[asteinberg]

The first article mentions a rewritten NTFS driver that supports read/write - I thought that the NTFS driver is still (and always will be, aside from the recent story about using Windows' ntfs.dll) considered "experimental", right? Perhaps it will still be labeled that way but will actually be solid enough to use? Anyone know?

Also, the second article mentions potential problems with usb mass storage devices (flash card readers, digital cameras, etc.) but never really draws any conclusions about how they will work - any ideas here?

Re:usb-storage and ntfs

[Josh Booth]

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.

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.: /dev/sg0).

both their fault..

[molo]

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

Linux SCSI subsystem a gripe of JS for years

[Spoing]

Linus and Joerg Schilling, author of cdrtools disagree on whether the problems are with Linux or the application software.

Joerg has complained about Linux for years (4? +5?), and generally perfers the SCSI subsystem in Solaris.

ACPI

[osho_gg]

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.