Kernel Traffic #233 For 4�Oct�2003

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

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. :)

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.