Kernel Traffic Zack Brown

If you like Kernel Traffic and want to send me a little money, click here:
Jan-Benedict

Adrian Bunk announced:

The patch below tries to implement a better i386 CPU selection.

In 2.4 selecting e.g. M486 has the semantics to get a kernel that runs on a 486 and above.

In 2.6 selecting M486 means that only the 486 is supported.

The help text for the X86_GENERIC option says it generates a generic kernel but the implementation is that it supports CPUs of the selected M* option and above.

There are two different needs:

  1. the installation kernel of a distribution should support all CPUs this distribution supports (perhaps starting with the 386)
  2. a sysadmin might e.g. want a kernel that support both a Pentium-III and a Pentium 4, but doesn't need to support a 386

The implementation in 2.4 was near to satisfy need 2., if X86_GENERIC in 2.6 was implemented as the help text says it would satisfy the need of 1.

The patch below against 2.6.0-test4-mm5 does a different implementation that lets you select all CPUs you want to support and it should therefore suit both needs.

Changes:

  • changed the i386 CPU selection from a choice to single options for every cpu
  • renamed the M* variables to CPU_*, this is needed to ask the users upgrading from older kernels instead of silently changing the semantics
  • AMD Elan is a different subarch, you can't configure a kernel that runs on both the AMD Elan and other i386 CPUs
  • help text changes

Questions/TODO:

  • @Rusty:
    what's your opinion on making MODULE_PROC_FAMILY in include/asm-i386/module.h some kind of bitmask?
  • @Robert:
    there were no Elan CFLAGS in arch/i386/Makefile???
  • which CPUs exactly need X86_ALIGNMENT_16?
  • X86_GOOD_APIC: are there really that many processors with a bad APIC?
  • could someone with a deeper knowledge of i386 CPUs comment on whether I got the CFLAGS in arch/i386/Makefile right for all possible CPU combinations?
  • Kconfig handling of no CPU selected

Regarding support for the 386, Jan-Benedict Glaw remarked, So far, no major distribution does support an i386. Basically, this has leaked in by some broken patch to libstdc++ which was not observed for a long time. To support i386, an additional emulator for additional i486 needs to be compiled-in, too. I had a short try to port Debian's patch into 2.6.x, but it oopsed :-> If I get some time, I'll finish that. Before we have thie i486-emu-for-i386 in, i386 support in the kernel doesn't make *any* sense on it's own... But Adrian said this wasn't directly related to the point raised in his announcement, that "the installation kernel of a distribution should support all CPUs this distribution supports". Jan-Benedict said he'd understood that, but only intended to make a peripheral remark.

Robert Schwebel also replied to Adrian's initial post, suggesting, Did you look at how rmk does CPU selection in the ARM tree? He has developed a very sophisticated scheme as there are lots of completely different cpu implementations, using a few cores. It might be an idea to make the schemes more uniform than they are now. Adrian said he hadn't looked at the ARM makefiles, but that he would now; and thanked Robert for the pointer. Robert also asked how the PPC folks handled CPU selection, and Tom Rini said, We don't allow for one kernel to work on something outside of a 'family', nor do we (aside from MULTIPLATFORM) allow a kernel to work on > 1 board type (maybe we'll fix that in 2.7). You can pick 8xx (MPC8xx line), 8260 (MPC826x/MPC827x, and should be fixed up to into classic), 6xx/7xx/74xx (aka 'classic' PPC, 40x and 44x.

Disks: IDE Disks: SCSI PCI Serial ATA J.A. Magallon

Jeff Garzik announced:

Just some minor updates. The main one is that ATA software reset is now considered reliable, so it is now the default. Execute-Device-Diagnostic bus reset method remains in place and can be easily re-enabled with a flag.

libata has also moved (slightly) to a new home: ftp://ftp.kernel.org/pub/linux/kernel/people/jgarzik/libata/

The latest libata patches for 2.4.x and 2.6.x were uploaded to this URL, and future patches will appear in the same location.

Look for more updates this weekend, including bug fixes from Dell and Red Hat, and better MMIO support. And maybe a special surprise. :)

J.A. Magallon asked if there were any user documentation floating around, so he could write the kernel configuration entries. Jeff replied:

The 2.5 patch should have Configure.help entries. Any assistance in writing documentation is greatly appreciated, though :) I hope to get much more than just a dry API reference in Documentation/Docbook/libata.tmpl, so any added information should probably be noted in there.

No user documentation, but feel free to ask me questions. Here's a quick overview:

ata_piix, ata_via -- low-level driver modules libata -- shared code module for the above

modprobe ata_piix or ata_via, and it will make your SATA devices appear as a new SCSI bus. Each SATA port is represented by a separate SCSI bus.

Currently in 2.4 and 2.6, both ATA and ATAPI devices appear as SCSI devices. However in 2.7, ATA devices (i.e. hard drives) will not go through the SCSI layer. ATAPI devices will continue to use some of the SCSI layer code in 2.7.

Currently only Intel ICH5 SATA is well tested. VIA SATA was just added, and Intel PATA support exists, but it is recommended that you use drivers/ide for PATA support.

Current -ac and -pac kernels #if-0 the ICH5 SATA pci id from drivers/ide/pci/piix.c, preferring to let libata drive that. That's done not only to expose libata to testing, but also for pragmatic reasons: drivers/ide will hang on many ICH5 SATA hosts, when they are in "native mode"[1].

[1] native mode is when a PCI IDE device is configured to obtain all its resources from the PCI io space, and use PCI interrupts. The other side of the coin is legacy mode, which uses legacy IDE ports 0x1f0/0x170 and legacy ISA irqs 14/15.

Hugo Mills asked, Do you have any plans to support SiI3112 in libata? The current SiI3112 drivers in the kernel just don't seem to work right on my hardware. :( Jeff replied, Yes! It should be fairly quick to add Silicon Image SATA support, too. It's all about finding the time to do it ;-) Hopefully some time in the next week or two...