Table Of Contents
|1.||11 Feb 2005 - 1 Mar 2005||(31 posts)||Support For Fujitsu LifeBook PS/2 Touchscreen Hardware|
|2.||18 Feb 2005 - 1 Mar 2005||(20 posts)||Bootsplash For 2.6.11-rc4|
|3.||19 Feb 2005 - 25 Feb 2005||(9 posts)||Failed Attempt To Restructure /sys|
|4.||23 Feb 2005 - 1 Mar 2005||(53 posts)||Linux 2.6.11-rc5 Released|
|5.||23 Feb 2005 - 28 Feb 2005||(14 posts)||PCI Bridge Driver Rewrite|
|6.||24 Feb 2005 - 25 Feb 2005||(12 posts)||Seeking Kernel Policy Documentation|
|7.||25 Feb 2005 - 26 Feb 2005||(6 posts)||Merging The Xen Code|
|8.||26 Feb 2005 - 28 Feb 2005||(16 posts)||Partition Recognition|
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 firstname.lastname@example.org
|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"
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 2005 - 1 Mar 2005 (20 posts) Archive Link: "Bootsplash for 2.6.11-rc4"
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 2005 - 25 Feb 2005 (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 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 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:
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:
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 MacDonald, Randy Dunlap, Horst von Brand
Stuart MacDonald said:
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 2005 - 26 Feb 2005 (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 2005 - 28 Feb 2005 (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.
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 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.