Kernel Traffic #301 For 2 Apr 2005

By Zack Brown

Table Of Contents

Mailing List Stats For This Week

We looked at 1684 posts in 10MB. See the Full Statistics.

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

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

These stats generated by mboxstats version 2.2

1. Support For Fujitsu LifeBook PS/2 Touchscreen Hardware

11 Feb 2005 - 1 Mar 2005 (31 posts) Archive Link: "[rfc/rft] Fujitsu B-Series Lifebook PS/2 TouchScreen driver"

Topics: Touchscreen

People: Vojtech PavlikKenan EsauArjan 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 2005 - 1 Mar 2005 (20 posts) Archive Link: "Bootsplash for 2.6.11-rc4"

Topics: Bootsplash

People: Pavel MachekMichal JanuszewskiGreg 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 ( , 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 2005 - 25 Feb 2005 (9 posts) Archive Link: "[PATCH] Symlink /sys/class/block to /sys/block"

Topics: FS: sysfs, Hot-Plugging

People: Chris WedgwoodGreg KHKay Sievers

In response to an earlier discussion ( , 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 2005 - 1 Mar 2005 (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 2005 - 28 Feb 2005 (14 posts) Archive Link: "[RFC] PCI bridge driver rewrite"

Topics: FS: sysfs, Hot-Plugging, PCI

People: Adam BelayGreg 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 2005 - 25 Feb 2005 (12 posts) Archive Link: "Linus' decrees?"

People: Stuart MacDonaldRandy DunlapHorst von Brand

Stuart MacDonald said:

Recently I ran across

Is there a collection point for Linus' decrees?

The LSB ( 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 2005 - 26 Feb 2005 (6 posts) Archive Link: "Re: arch/xen is a bad idea"

People: Andrew MortonIan PrattAndi 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 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 2005 - 28 Feb 2005 (16 posts) Archive Link: "[PATCH] partitions/msdos.c"

Topics: FS: ReiserFS, Hot-Plugging, USB

People: Andries BrouwerLinus TorvaldsUwe 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.







Sharon And Joy

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 All pages on this site are copyright their original authors, and distributed under the terms of the GNU General Public License version 2.0.