Kernel Traffic #301 For 2 Apr 2005

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.

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

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.

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)

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.

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?

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.

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.