Kernel Traffic #233 by Zack Brown

                        Kernel Traffic #233 For 4 Oct                          
                                                                               
                                 By Zack Brown                                 
                                                                               
If you like Kernel Traffic and want to send me a little money, click here:

https://www.paypal.com/xclick/business=zbrown%40tumblerings.org&no_note=1&tax=0&currency_code=USD
Table Of Contents

  * Standard Format
  * Text Format
  * XML Source
  * Threads Covered
   
    1. 7 Sep  - 16 Sep   (49 posts) Improving CPU Detection
    2. 12 Sep  - 16 Sep  (16 posts) libata Update          
   
 

1. Improving CPU Detection
7 Sep  - 16 Sep  (49 posts) Subject: "RFC: [2.6 patch] better i386 CPU
selection"
People: Adrian Bunk, Jan-Benedict Glaw, Robert Schwebel, Tom Rini

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

 

2. libata Update
12 Sep  - 16 Sep  (16 posts) Subject: "libata update posted"
Topics: Disks: IDE, Disks: SCSI, Serial ATA
People: Jeff Garzik, Hugo Mills, 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..."

 

 

 

 

 

 

                       We Hope You Enjoy Kernel Traffic                        
                                                                               

 Kernel Traffic is hosted by the generous folks at Tux.Org. All pages on this  
 site are copyright their original authors, and distributed under the terms of 
                 the GNU General Public License, version 2.0.