Kernel Traffic #324 For 4 Sep 2005

By Zack Brown

Table Of Contents

Mailing List Stats For This Week

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

There were 610 different contributors. 242 posted more than once. The average length of each message was 84 lines.

The top posters of the week were: The top subjects of the week were:
69 posts in 408KB by blaisorblade
57 posts in 293KB by steven rostedt
49 posts in 168KB by andi kleen
34 posts in 231KB by con kolivas
30 posts in 106KB by alan cox
 44 posts in 212KB for "[patch] i386 no-idle-hz aka dynamic-ticks 3"
42 posts in 197KB for "[rfc] [patch] cache pollution aware __copy_from_user_ll()"
37 posts in 138KB for "ncq support nvidia nforce4 (ck804) sataii"
33 posts in 138KB for "[patch] ide: don't offer ide_generic on ia64"
27 posts in 188KB for "[rfc][patch 2.6.13-rc6] add dell systems management base driver (dcdbas) with sysfs support"

These stats generated by mboxstats version 2.8

1. Abortive Attempt To Remove Support For Older GCC Versions

31 Jul 2005 - 13 Aug 2005 (25 posts) Archive Link: "[2.6 patch] remove support for gcc < 3.2"

People: Adrian Bunk, David S. Miller, Bill Davidsen, Kurt Wall, Willy Tarreau, Gustavo Guillermo Perez, Miles Bader, Nigel Cunningham

Adrian Bunk said:

This patch removes support for gcc < 3.2 .

The advantages are:

My personal opinion about the time and space a compilation requires is that this is no longer that much of a problem for modern hardware, and in the worst case you can compile the kernels for older machines on more recent machines.

This patch does not yet remove all the #ifdef's and other things that are now no longer required, it only let's the compilation #error for older gcc versions and updates the documentation.

I'd like to see this patch in the next -mm, and if noone will tell a strong reason for keeping support for these gcc versions I'll send the cleanups that are now.

David S. Miller replied:

Many people still use 2.95 because it's still the fastest way to get a kernel build done and that's important for many people.

And with 4.0 being a scary regression in the compile time performance area compared to 3.4, this becomes even more important to keep around.

Nigel Cunningham also wanted 2.95 support. And Bill Davidsen said, "I don't mean to offend anyone, but it seems that the gcc project, at least WRT x86, has lost its way a bit. The compiler is getting slower, and the generated code is not getting correspondingly faster. Or smaller. I'm not sure about more correct... Keeping 2.95 might not be a bad idea." Elsewhere, Kurt Wall also said, "Environments that require kernel compilation, often multiple times, testing, benefit from shorter compile times. It can be the difference between, say, completing a test suite overnight instead of having to wait until tomorrow afternoon. Keeping 2.95, at least, has some value in such environments." Willy Tarreau added, "I *do* still use 2.95 a lot, and I'm not alone, judging from people around me. 2.95 has been the reference for a very long time, that's why it's still so much present. 3.0 and 3.1 (even 3.2) have been there for a very short time frame, but 2.95 and 3.3 really seem to be references compilers. So please keep support for 2.95." Miles Bader also thought Adrian's patch was a bad idea. Gustavo Guillermo Perez also said, "Please keep the 2.95 support I use to use a lot, on not new hardware. If you have old hardware with not much resources gcc 2.95 works just fine and fast, even you build the main kernel on other machine, by compatibility issues one or two drivers should be builded a lot of times into the older hardware, then we are forced to build gcc 3.4 or something like."

There was no conclusion during the thread, but with such a vocal outcry, it's doubtful a patch like Adrian's will be accepted in the near to middle term.

2. Linux 2.6.13-rc5 Released

1 Aug 2005 - 17 Aug 2005 (39 posts) Archive Link: "Linux 2.6.13-rc5"

Topics: Kernel Release Announcement

People: Linus Torvalds

Linus Torvalds announced Linux 2.6.13-rc5, saying:

Ok, one more in the series towards final 2.6.13.

This one is small enough that both shortlog and diffstat fit comfortably: no big architecture updates or anything like that. Some input, x86-64 and ppc updates, and various fairly small fixes in random places.

Some reverts back to 2.6.12 behaviour - you've seen the discussions, and I'm sure we'll end up discussing things further for a long while still, but the plan is to release 2.6.13 with known behaviour characteristics.

Give it a good testing, I'm hoping this can really turn into 2.6.13.

3. NVidia Still Hostile To Free Software

10 Aug 2005 - 18 Aug 2005 (37 posts) Archive Link: "NCQ support NVidia NForce4 (CK804) SATAII"

Topics: Serial ATA

People: Michael Thonke, Jeff Garzik, Allen Martin, Lee Revell, Chris Wedgwood

Michael Thonke asked, "what the plans/timeplan to implement NCQ support for NVidia NForce4(CK804) SATAII based chipsets? Fact is that is it possible to use NCQ with NForce4 SATAII on Windows system, I wonder why it isn't support by libata?" Jeff Garzik replied, "Ask NVIDIA. They are the only company that gives me -zero- information on their SATA controllers. As such, there are -zero- plans for NCQ on NVIDIA controllers at this time." Elsewhere, Allen Martin from NVidia said, "Likely the only way nForce4 NCQ support could be added under Linux would be with a closed source binary driver, and no one really wants that, especially for storage / boot volume. We decided it wasn't worth the headache of a binary driver for this one feature. Future nForce chipsets will have a redesigned SATA controller where we can be more open about documenting it." Some posts down the line, Lee Revell remarked, "Nvidia is not Linux friendly. Their business is making hardware so people can play games on Windows. Anything that their lawyers think might have a 0.0001% chance of interfering with that business model in the slightest bit will not happen." Elsewhere, Chris Wedgwood recommended, "keeping constant pressure of vendors like nvidia about openness is probably the best we can do right now (obviously this means avoiding buying their products as much as possible)."

4. Simplifying The Driver-Handling Code

10 Aug 2005 - 17 Aug 2005 (11 posts) Archive Link: "[PATCH] Don't use a klist for drivers' set-of-devices"

People: Alan Stern, Christoph Hellwig, Dmitry Torokhov, Greg KH

Alan Stern said:

This patch (as536) simplifies the driver-model core by replacing the klist used to store the set of devices bound to a driver with a regular list protected by a mutex. It turns out that even with a klist, there are too many opportunities for races for the list to be used safely by more than one thread at a time. And given that only one thread uses the list at any moment, there's no need to add all the extra overhead of making it a klist.

This version of the patch addresses the concerns raised earlier by Pat: the list and mutex have been given more succinct names, and the obscure special-case code in device_attach has been replaced with a FIXME comment. Note that the new iterators in driver.c could easily be changed to use list_for_each_entry_safe and list_for_each_entry, if the functions didn't offer the feature of starting in the middle of the list. If no callers use that feature, it should be removed.

I still think the APIs for device_bind_driver and device_release_driver need to be changed, because they each rely on dev->drv not changing at a time when no protecting locks are held. They will have to be fixed up in a later patch.

Greg KH said that avoiding races and simplifying the code was the reason klists were introduced in the first place, and Christoph Hellwig remarked, "And shows once more that the klist approach was totally misguided."

Alan avoided the debate, but did remark, "Do note that the bus's list of devices and the bus's list of registered drivers are still klists. Only the driver's list of bound devices gets reverted to a normal list."

Dmitry Torokhov proposed an exploit, saying, "what do I do in the following scenario - I have a serio port (AUX) that has a synaptics touchpad bound to it which is driven by psmouse driver. psmouse driver registers a child port (synaptics pass-through) during probe call. The child port is also driven by psmouse module - but it looks like it will deadlock when binding. Am I missing something here?" Alan confessed, "I hate to say this, but you are right. Can you suggest a way around this problem? Perhaps arranging things so that the devlist_mutex is held only during the actual __device_bind_driver call and not during probe... But there are so many tricky interactions and possible races that this requires a lot of thought." Over the next day he did think about it, and then said:

Dmitry's point is well founded. Greg, I want to retract that klist patch (as536). I'll send in a revised version before long.

It looks like the best approach will simply be to eliminate the driver's list of bound devices altogether. That should make Christoph happy -- no klist, no list, no nothing! :-) The list hardly ever gets used, mainly when the driver is unloaded. We can already get the same effect by iterating over the bus's list of devices and skipping everything not bound to the driver.

This will eliminate a whole set of races and make the code more transparent (I hope).

Several days later, he said:

This is a revised version of the patch I sent in last week -- not yet a submission, more of an RFC. It turns out that removing the driver's list of bound devices isn't practical, because there are times when a device not yet on the bus's overall klist will be bound (this happens whenever a new device is registered, for instance).

Anyway, in this new version the locking is greatly simplified and the requirements are made much more explicit in the comments. This code will not be subject to deadlock when a driver's probe routine registers a child device that uses the same driver, or when a remove routine unregisters a child device from the same driver. I think this version is okay, but please look it over and see if anything looks amiss.

The next step will be to clean up the races inherent in device_bind_driver and device_release_driver. There are two obvious approaches:

Pass the driver as an argument rather than trusting the value stored in dev->driver.

Require the caller to lock dev->sem.

On the face of it, neither is particularly more attractive than the other. However, reading through the various places that call these routines (for example, drivers/input/serio/serio.c or drivers/pnp/card.c) revealed a pattern. In most cases, the callers of device_bind_driver _really_ want something that functions more like driver_probe_device but without the matching step. The callers are invoking the probe methods by hand rather than relying on the driver core to do so. There's maybe only one place where a caller actually does want the device bound to the driver without doing a probe.

This suggests it might be a good idea to split driver_probe_device into two pieces, one for matching and one for probing & binding. The second piece could then be used instead of device_bind_driver.

Another thing became apparent as well. All of the places that use these routines currently rely on the bus subsystem's rwsem for synchronization. Obviously this is bad, because that rwsem is on its way out. I don't know enough about all those different drivers to be able to tell whether they lock the rwsem merely because the old API required it or because they really do need some mutual exclusion. Still, this suggests that it might be best to require the callers to lock dev->sem -- i.e., use dev->sem sort of as a replacement for the bus rwsem.

5. Unifying Watchdog Names In /dev

13 Aug 2005 - 18 Aug 2005 (13 posts) Archive Link: "[PATCH] Watchdog device node name unification"

People: Henrik Brix Andersen, Linus Torvalds, Olaf Hering

Henrik Brix Andersen said, "Here's a patch for unifying the watchdog device node name to /dev/watchdog as expected by most user-space applications." Linus Torvalds apparently liked the patch, but replied, "Doesn't seem to be serious enough to be worth it at this late stage in the 2.6.13 game. Can you re-send after I do a release?" Henrik agreed. Olaf Hering remarked, "A patch like that is sitting in -mm since almost 5 months. I wonder why it was never merged," but there was no reply.

6. Stable Linux 2.6.12.5 Released

14 Aug 2005 (2 posts) Archive Link: "Linux 2.6.12.5"

People: Chris Wright

Chris Wright said:

We (the -stable team) are announcing the release of the 2.6.12.5 kernel.

The diffstat and short summary of the fixes are below.

I'll also be replying to this message with a copy of the patch between 2.6.12.4 and 2.6.12.5, as it is small enough to do so.

The updated 2.6.12.y git tree can be found at:
rsync://rsync.kernel.org/pub/scm/linux/kernel/git/chrisw/linux-2.6.12.y.git
and can be browsed at the normal kernel.org git web browser:
www.kernel.org/git/ (http://www.kernel.org/git/)

7. watchdoc-mm Development Migrating From BitKeeper To git

17 Aug 2005 (2 posts) Archive Link: "watchdog-mm git tree"

Topics: Version Control

People: Wim Van Sebroeck

Wim Van Sebroeck said, "I (finaly) converted the watchdog-mm bitkeeper tree to a git repository: rsync://rsync.kernel.org/pub/scm/linux/kernel/git/wim/linux-2.6-watchdog-mm.git" .

 

 

 

 

 

 

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.