Kernel Traffic #324 by Zack Brown

                        Kernel Traffic #324 For 4 Sep 

                                 By Zack Brown

Table Of Contents

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

    1. 31 Jul  - 13 Aug  (25      Abortive Attempt To Remove Support For Older
                         posts)   GCC Versions
    2. 1 Aug  - 17 Aug   (39      Linux 2.6.13-rc5 Released
                         posts)
    3. 10 Aug  - 18 Aug  (37      NVidia Still Hostile To Free Software
                         posts)
    4. 10 Aug  - 17 Aug  (11      Simplifying The Driver-Handling Code
                         posts)
    5. 13 Aug  - 18 Aug  (13      Unifying Watchdog Names In /dev
                         posts)
    6. 14 Aug            (2       Stable Linux 2.6.12.5 Released
                         posts)
    7. 17 Aug            (2       watchdoc-mm Development Migrating From
                         posts)   BitKeeper To git

Mailing List Stats For This Week

We looked at 1730 posts in 10MB.

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

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

Full Statistics generated by mboxstats version 2.8

 

1. Abortive Attempt To Remove Support For Older GCC Versions
31 Jul  - 13 Aug  (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:

      + reducing the number of supported gcc versions from 8 to 4 (support
        removed: 2.95, 2.96, 3.0, 3.1; still supported: 3.2, 3.3, 3.4, 4.0)
        allows the removal of several #ifdef's and workarounds
      + my impression is that the older compilers are only rarely used, so
        miscompilations of a driver with an old gcc might not be detected for a
        longer amount of time

    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  - 17 Aug  (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  - 18 Aug  (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  - 17 Aug  (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  - 18 Aug  (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  (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  (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.