Kernel Traffic #301 by Zack Brown

                        Kernel Traffic #301 For 2 Apr 

                                 By Zack Brown

Table Of Contents

  * Standard Format
  * Text Format
  * XML Source
  * Mailing List Stats For This Week
  * Threads Covered

    1. 11 Feb  - 1 Mar   (31      Support For Fujitsu LifeBook PS/2 Touchscreen
                         posts)   Hardware
    2. 18 Feb  - 1 Mar   (20      Bootsplash For 2.6.11-rc4
                         posts)
    3. 19 Feb  - 25 Feb  (9       Failed Attempt To Restructure /sys
                         posts)
    4. 23 Feb  - 1 Mar   (53      Linux 2.6.11-rc5 Released
                         posts)
    5. 23 Feb  - 28 Feb  (14      PCI Bridge Driver Rewrite
                         posts)
    6. 24 Feb  - 25 Feb  (12      Seeking Kernel Policy Documentation
                         posts)
    7. 25 Feb  - 26 Feb  (6       Merging The Xen Code
                         posts)
    8. 26 Feb  - 28 Feb  (16      Partition Recognition
                         posts)

Mailing List Stats For This Week

We looked at 1684 posts in 10MB.

There were 608 different contributers. 218 posted more than once. The average
length of each message was 96 lines.

 The top posters of the            The top subjects of the week were:
       week were:
69 posts in 417KB by      56 posts in 290KB for "[Lse-tech] Re: A common layer
Adrian Bunk               for Accounting packages"
54 posts in 215KB by      38 posts in 197KB for "2.6.11-rc5"
Andrew Morton             33 posts in 130KB for "Xterm Hangs - Possible
43 posts in 408KB by      scheduler defect?"
Andreas Gruenbacher       32 posts in 256KB for "[PATCH 2/2] page table
41 posts in 158KB by Greg iterators"
KH                        31 posts in 197KB for "[rfc/rft] Fujitsu B-Series
29 posts in 206KB by      Lifebook PS/2 TouchScreen driver"
[email protected]

Full Statistics generated by mboxstats version 2.2

 

1. Support For Fujitsu LifeBook PS/2 Touchscreen Hardware
11 Feb  - 1 Mar  (31 posts) Archive Link: "[rfc/rft] Fujitsu B-Series Lifebook
PS/2 TouchScreen driver"
Topics: Touchscreen
People: Vojtech Pavlik, Kenan Esau, Arjan van de Ven

Vojtech Pavlik said:

    I've reimplemented the Lifebook touchscreen driver using libps2 and input,
    to make it short and fitting into the kernel drivers.

    Please comment on code and test for functionality!

    PS.: The driver should register two input devices. It doesn't yet, since
    that isn't very straightforward in the psmouse framework.

Kenan Esau was really happy to see this support being worked on, though he had
a lot of technical criticisms of the patch. One of his objections was that
there was no way to be certain a LifeBook touchscreen was present on the
system. Arjan van de Ven had a hard time swallowing this, and suggested ways of
detecting LifeBooks. But Kenan replied, "the lifebook-touchscreen hardware is
also used in other notebooks. For example the Panasonic Toughbook CF28. But we
could still use DMI to check whether we are on a lifebook b-series and then
initialize the hardware. This would still get 95% of all cases. For all the
other ones we would have to provide some kind of force-switch." Vojtech added,
"Or simply another entry in the DMI table for the Toughbook, and for the few
others who use this kind of touchscreen controller."

Later on, Kenan posted his own updated version of the patch, including DMI
probing. Vojtech, digging down into the code, found a lot of specific problems,
though he had no general objections to Kenan's direction.

 

2. Bootsplash For 2.6.11-rc4
18 Feb  - 1 Mar  (20 posts) Archive Link: "Bootsplash for 2.6.11-rc4"
Topics: Bootsplash
People: Pavel Machek, Michal Januszewski, Greg KH

Pavel Machek said, "Just in case someone is interested, this is bootsplash for
2.6.11-rc4, taken from suse kernel. I'll probably try to modify it to work with
radeonfb. Any ideas why bootsplash needs to hack into vesafb? It only uses
vesafb_ops to test against them before some kind of free..." Michal Januszewski
replied:

    It doesn't really need vesafb for anything. Back in the days of 2.6.7 I
    used to release a version of bootsplash that had the dep. on vesafb
    removed. It worked fine with at least some other fb drivers.

    You might also want to save yourself some work and try out an alternative
    solution called fbsplash (http://dev.gentoo.org/~spock/projects/gensplash/
    current/) , which I designed after I got tired of fixing bootsplash and
    which I actively maintain. Fbsplash provides virtually the same
    functionality, and it has as much code as possible moved into userspace (no
    more JPEG decoders in the kernel).

Greg KH agreed with Michal, saying that his version was very sane, stable, and
possibly even ready to be merged. Pavel agreed entirely, adding, "My only
requirement is that it works with radeonfb and similar low-level drivers (so
that I can get suspend-to-ram to work) and that it gets past our branding
people..." Michal replied, "I don't know about the branding people, but
suspend-to-ram and radeonfb shouldn't be a problem for fbsplash :)"

 

3. Failed Attempt To Restructure /sys
19 Feb  - 25 Feb  (9 posts) Archive Link: "[PATCH] Symlink /sys/class/block to
/sys/block"
Topics: FS: sysfs, Hot-Plugging
People: Chris Wedgwood, Greg KH, Kay Sievers

In response to an earlier discussion (http://marc.theaimsgroup.com/?m=
110506536315986) , Malcolm Rowe posted a patch to create /sys/class/block as a
symlink to /sys/block. Chris Wedgwood replied, "Shouldn't we really move /sys/
block to /sys/class/block and put the symlink from there to /sys/block with the
hope of removing it one day?" Greg KH replied, "When struct class_device can
support children, we can do just that. But that support has not been added,
yet..." Kay Sievers pointed out elsewhere, that "The hotplug events will still
have the /block/* devpath, so this symlink will give us nothing than problems."
After some back-and-forth, Greg admitted, "Ok, forget the symlink. Or, for that
matter, ever moving from /sys/block/..."

 

4. Linux 2.6.11-rc5 Released
23 Feb  - 1 Mar  (53 posts) Archive Link: "2.6.11-rc5"
Topics: Kernel Release Announcement, Serial ATA
People: Linus Torvalds

Linus Torvalds announced Linux 2.6.11-rc5, saying:

    Hey, I hoped -rc4 was the last one, but we had some laptop resource
    conflicts, various ppc TLB flush issues, some possible stack overflows in
    networking and a number of other details warranting a quick -rc5 before the
    final 2.6.11.

    This time it's really supposed to be a quickie, so people who can, please
    check it out, and we'll make the real 2.6.11 asap.

    Mostly pretty small changes (the largest is a new SATA driver that crept
    in, our bad). But worth another quick round.

 

5. PCI Bridge Driver Rewrite
23 Feb  - 28 Feb  (14 posts) Archive Link: "[RFC] PCI bridge driver rewrite"
Topics: FS: sysfs, Hot-Plugging, PCI
People: Adam Belay, Greg KH

Adam Belay said:

    For the past couple weeks I have been reorganizing the PCI subsystem to
    better utilize the driver model. Specifically, the bus detection code is
    now using a standard PCI driver. It turns out to be a major undertaking, as
    the PCI probing code is closely tied into a lot of other PCI components,
    and is spread throughout various architecture specific areas. I'm hoping
    that these changes will allow for a much cleaner and more functional PCI
    implementation.

    The basic flow of the new code is as follows:

     1. A standard "driver core" driver binds to a bridge device.
     2. When "*probe" is called it sets up the hardware and allocates a "struct
        pci_bus".
     3. The "struct pci_bus" is filled with information about the detected
        bridge.
     4. The driver then registers the "struct pci_bus" with the PCI Bus Class.
     5. The PCI Bus Class makes the bridge available to sysfs.
     6. It then detects hardware attached to the bridge.
     7. Each new PCI bridge device is registered with the driver model.
     8. All remaining PCI devices are registered with the driver model.

    Steps 7 and 8 allow for better resource management.

    I've attached an early version of my code. It has most of the new PCI bus
    class registration code in place, and an early implementation of the
    PCI-to-PCI bridge driver. The following remains to be done:

     1. refine and cleanup the new PCI Bus API
     2. export the new API in "linux/pci.h", and cleanup any users of the old
        code.
     3. fix every PCI hotplug driver.
     4. write a bridge driver for the PCI root bridge
     5. write a bridge driver for Cardbus hardware
     6. refine device registration order
     7. redesign PCI bus number assignment and support bus renumbering
     8. redesign PCI resource management to be compatible with the new code
     9. testing on various architectures
    10. Write "*suspend" and "*resume" routines for PCI bridges. Any ideas on
        what needs to be done?
    11. fix "PCI_LEGACY" (I may have broke it, but it should be trivial)

There were various comments and suggestions, but Greg KH also said, "I like it
all :). If you want to submit patches now that rearrange the code to make it
easier for you to modify in the future to achieve the above goals, feel free,
I'll gladly take them." And Adam replied, "I'm going to do an updated release
soon. It should take care of some of the issues on the TODO list and also will
be based on previous feedback. From there, I'll start planning a strategy for
merging with mainline."

 

6. Seeking Kernel Policy Documentation
24 Feb  - 25 Feb  (12 posts) Archive Link: "Linus' decrees?"
People: Stuart MacDonald, Randy Dunlap, Horst von Brand

Stuart MacDonald said:

    Recently I ran across http://groups.google.ca/groups?hl=en&lr=lang_en&safe=
    off&selm=1033074519.2698.5.camel%40localhost.localdomain

    Is there a collection point for Linus' decrees?

    The LSB (http://www.linuxbase.org/) seems to be mostly involved with how a
    distro is laid out, and not much to do with the kernel.

Some posts down the line, Randy Dunlap said he didn't know of anyplace that
collected kernel policies, though he liked the idea. Horst von Brand proposed a
Documentation/policies file, and Stuart said that would be great.

 

7. Merging The Xen Code
25 Feb  - 26 Feb  (6 posts) Archive Link: "Re: arch/xen is a bad idea"
People: Andrew Morton, Ian Pratt, Andi Kleen

Andrew Morton said:

    The Xen team still believe that it's best to keep arch/xen, arch/xen/i386,
    arch/xen/x86_64, etc. And I believe that Andi (who is the world expert on
    maintaining an i386 derivative) thinks that this is will be a long-term
    maintenance problem.

    I tend to agree with Andi, and I'm not sure that the Xen team fully
    appreciate the downside of haveing an own-architecture in the kernel.org
    kernel and the upside of having their code integrated with the
    most-maintained architecture. It could be that the potential problems
    haven't been sufficiently well communicated.

    Christian has mentioned that Xen would need to hook into the i386 code in
    ~60 places, which is somewhat more than Ian's 37-bullet-point list.

    I get the impression that the Xen team are overly reluctant to make changes
    to the arch/i386 code and to arch-neutral kernel code. Don't do that - new
    abstractions, refactoring and generally moving things about is generally a
    safe thing to do, and can often make things better anyway.

    So. Has anyone changed position or otherwise converged? How do we get this
    resolved?

Ian Pratt replied:

    I think there's an interim compromise position that everyone might go for:

    Phase 1 is for us to submit a load of patches that squeeze out the low
    hanging fruit in unifying xen/i386 and i386. Most of these will be strict
    cleanups to i386, and the result will be to almost halve the number of
    files that we need to modify.

    The next phase is that we re-organise the current arch/xen as follows:

    We move the remaining (reduced) contents of arch/xen/i386 to arch/i386/xen
    (ditto for x86_64). We then move the xen-specific files that are shared
    between all the different xen architectures to drivers/xen/core. I know
    this last step is a bit odd, but it's the best location that Rusty Russel
    and I could come up with.

    At this point, I'd hope that we could get xen into the main-line tree.

    The final phase is to see if we can further unify more native and xen
    files. This is going to require some significant i386 code refactoring, and
    I think its going to be much easier to do if all the code is in the
    main-line tree so that people can see the motivation for what's going on.

Andi Kleen seemed favorable, though he still had some questions to resolve.
Andrew also liked the compromise, and also had questions to resolve. But he
said, "The main objective is to minimise code duplication. The question of
where in the tree all the resulting code actually lands is secondary from a
maintainability POV."

 

8. Partition Recognition
26 Feb  - 28 Feb  (16 posts) Archive Link: "[PATCH] partitions/msdos.c"
Topics: FS: ReiserFS, Hot-Plugging, USB
People: Andries Brouwer, Linus Torvalds, Uwe Bonnes

Andries Brouwer said:

    A well-known kernel bug is that it guesses at the partition type and the
    partitions on any disk it encounters. This is bad because needless I/O is
    done, slowing down the boot, sometimes quite a lot, especially when I/O
    errors occur. And it is bad because sometimes we guess wrong.

    In other words, we need the user space command `partition', where
    "partition -t dos /dev/sda" reads a DOS-type partition table. (And
    "partition /dev/sda" tries all known heuristics to decide what type of
    partitioning might be present.) The two variants are: (i) partition tells
    the kernel to do the partition table reading, and (ii) partition uses partx
    to read the partition table and tells the kernel one-by-one about the
    partitions found this way.

    Since this is a fundamental change, a long transition period is needed, and
    that period could start with a kernel boot parameter telling the kernel not
    to do partition table parsing on a particular disk, or a particular type of
    disks, or all disks.

    This could have been the intro to a patch doing that, but is not. (It is
    just an RFC.)

    The tiny patch below prompted the above - it was suggested by Uwe Bonnes
    who encountered USB devices without partition table where our present
    heuristics did not suffice to stop partition table parsing. It causes the
    kernel to ignore partitions of type 0. A band-aid.

    I think nobody uses such partitions seriously, but nevertheless this should
    probably live in -mm for a while to see if anybody complains.

Linus Torvalds got behind the patch, and after some discussion said, "I'll put
it in immediately after doing a 2.6.11 (no need to worry about getting into
2.6.11, since afaik the worst problem right now is an extra partition that
isn't usable)." Uwe Bonnes remarked, "Well, on a Suse 9.2 System with Suse
Hotplug, the phantom partition was somehow recognized as Reiserfs, and then the
Hotplug mechanism trying to mount the bogus partition as a Reiser Filesystem
ended in an Oops..." Linus acknowledged that this was a significant case,
though he felt it indicated that "reiserfs is not doing very well on the
sanity-checking front." He and Andries urged folks to report all oopses.

 

 

 

 

 

 

                       We Hope You Enjoy Kernel Traffic
                                        

Kernel Traffic is grateful to be developed on a computer donated by Professor
Greg Benson and Professor Allan Cruse in the Department of Computer Science at
the University of San Francisco. This is the same department that invented
FlashMob Computing. Kernel Traffic is hosted by the generous folks at
kernel.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.