Kernel Traffic #229 by Zack Brown

                        Kernel Traffic #229 For 8 Sep                          
                                                                               
                                 By Zack Brown                                 
                                                                               
If you like Kernel Traffic and want to send me a little money, click here:

https://www.paypal.com/xclick/business=zbrown%40tumblerings.org&no_note=1&tax=0&currency_code=USD
Table Of Contents

  * Standard Format
  * Text Format
  * XML Source
  * Mailing List Stats For This Week
  * Threads Covered
   
    1. 11 Aug  - 14 Aug  (27      Code-Formatting Patches And BitKeeper        
                         posts)   Revision History                             
    2. 11 Aug  - 16 Aug  (20      ext2 Corruption In 2.4.22-rc2                
                         posts)                                                
    3. 12 Aug  - 14 Aug  (10      Pre-Loading Modules Before Bootup            
                         posts)                                                
    4. 13 Aug  - 17 Aug  (18      Linux 2.6.0-test3-mm2 Released               
                         posts)                                                
    5. 14 Aug  - 18 Aug  (16      /proc/kcore May Be Going Away                
                         posts)                                                
    6. 18 Aug            (12      Development Strategy For Unmaintained Drivers
                         posts)                                                
    7. 20 Aug            (1 post) New AEM (Asynchronous Event Mechanism) For   
                                  Linux                                        
    8. 20 Aug  - 21 Aug  (2       FUSD v1.10 Released                          
                         posts)                                                
   
Mailing List Stats For This Week

We looked at 2320 posts in 10655K.

There were 527 different contributors. 289 posted more than once. 211 posted
last week too.

The top posters of the week were:

  * 94 posts in 366K by Greg KH
  * 73 posts in 268K by Con Kolivas
  * 69 posts in 259K by Jamie Lokier
  * 68 posts in 215K by Jeff Garzik
  * 44 posts in 216K by Matt Mackall
  * Full Stats

 

1. Code-Formatting Patches And BitKeeper Revision History
11 Aug  - 14 Aug  (27 posts) Subject: "[PATCH] CodingStyle fixes for
drm_agpsupport"
Topics: Version Control
People: Larry McVoy, Eli Carter, Philip Brown, Dave Jones

Dave Jones posted some formatting changes to a file, to make it conform more
closely to the CodingStyle document. Larry McVoy objected to the patch, in part
because, "It's a formatting only patch. That screws over people who are using
BK for debugging, now when I double click on these changes I'll get to your
cleanup patch, not the patch that was the last substantive change." Jeff
replied that in Linux development, CodingStyle patches were culturally
acceptable, as long as the developer kept each indifidual patch small. Larry
replied, "That ought to be balanced with "don't screw up the revision history,
people use it". It's one thing to reformat code that is unreadable, for the
most part this code didn't come close to unreadable." Eli Carter remarked, 
"perhaps the (revision control) tool is getting in the way of doing the job and
should be fixed? :) Perhaps being able to flag a changeset as a 'formatting
change', and have the option to hide it or make it 'transparent' in some
fashion? Hmm... "Annotate only the changes that relate to feature X."" Larry
said he'd thought about that and rejected it, and in fact, "we have a policy at
BitMover where "formatting changes" are prohibited and we make people redo
their changesets until they get them right." Philip Brown suggested, "You
should allow for changes that are "formatting change only", with no actual code
structural change. You could pass the results through stage 1 of gcc, and only
allow it if the parsing tree is identical." Larry replied that BitKeeper was
used for more than just GCC-compilable files. Eli asked, "I assume you can have
content-specific validators run before a commit? (CVS can.) A validator could
see that it was formatting only and mark it in someway perhaps?" Larry said
yes, BitKeeper had triggers, which could do what Eli wanted.

 

2. ext2 Corruption In 2.4.22-rc2
11 Aug  - 16 Aug  (20 posts) Subject: "2.4.22-rc2 ext2 filesystem corruption"
Topics: FS: ext2
People: Martin Maney, Marcelo Tosatti, Alan Cox, Stephan von Krawczynski

Martin Maney reported, "I've got a very repeatable file corruption under
2.4.22-rc2 that does not manifest under 2.4.21. My repeatable test case only
(so far?) causes the data in the file to be corrupted, but I suspect metadata
can get hit as well, and I have seen some filesystem errors that were probably
caused by this, but not so that I can say so with certainty." Stephan von
Krawczynski suggested running memtest to confirm there were no problems with
his RAM chips. And Marcelo Tosatti asked for a clear recipe to repeat the
corruption. Martin said that copying any large file (perhaps 50M in size)
across filesystems, and then umounting the destination filesystem would
reproduce the corruption. After remounting, the data would have changed.
Marcelo asked, "can you try to isolate the corruption. You said it didnt happen
with 2.4.21 -- which pre shows up the problem?" Martin replied, "The problem
appears only in rc2 (okay, assuming it's not a regression). With 2.4.21-rc1 the
file corruption I've been seeing does not happen." ... "I will also try an rc2
with unnecessary features omitted from the build. So far I've stayed with the
base config, but it's a config shared by most of the machines on the LAN and
thus has plenty of extras."

Marcelo thought the problem might have something to do with the Promise driver,
which changed in -rc2. He posted a patch to revert that change, but instead of
this, Martin disabled his Promise chip entirely. After that, he no longer
observed the corruption. Marcelo asked him to try again with the same hardware,
and just that one patch reverted, so they could be sure where the problem was.
Martin did this, and confirmed that the corruption could not be reproduced with
the patch reverted.

Having located the problem, Alan Cox pointed out that it would still be
necessary to audit the code in order to find a fix. There were a couple more
posts, and the thread petered out.

 

3. Pre-Loading Modules Before Bootup
12 Aug  - 14 Aug  (10 posts) Subject: "multibooting the linux kernel"
Topics: FS: initramfs, FS: ramfs
People: Nufarul Alb, Christoph Hellwig, H. Peter Anvin

Nufarul Alb posted a patch (http://home.t-online.de/home/ChristianK./patches/)
that made it possible to pre-load modules before the kernel actually booted.
Christoph Hellwig pointed out that Nufarul's patch was against 2.4, and so did
not have much chance of being accepted. He suggested porting the work to
2.6-test and resubmitting it. He also suggested coding in the Linux style
rather than the GNU style. Nufarul clarified, "Those are not my patches. They
belong to a certain Christian Koenig. He doesn't mantain them any more and I'm
searching for someone to mantain this project." H. Peter Anvin suggested just
using initramfs instead.

 

4. Linux 2.6.0-test3-mm2 Released
13 Aug  - 17 Aug  (18 posts) Subject: "2.6.0-test3-mm2"
Topics: Framebuffer
People: Peter Osterlund, Andrew Morton

Andrew Morton announced 2.6.0-test3-mm2 (ftp://ftp.kernel.org/pub/linux/kernel/
people/akpm/patches/2.6/2.6.0-test3/2.6.0-test3-mm2/) , saying it included
"zillions" of bugfixes, framebuffer updates, and some more CPU scheduler
tweaking. Peter Osterlund posted "a fix for synaptics touchpads with "multi
buttons". The patch comes from Hartwig Felger, who wrote the original multi
button support patch (p00003_synaptics-multi-button.patch). The same bug fix
has been included in the XFree86 driver for a few weeks, and seems to work
fine. (That part of the X driver is only used for 2.4 kernels.)"

 

5. /proc/kcore May Be Going Away
14 Aug  - 18 Aug  (16 posts) Subject: "[PATCH] Make modules work in Linus' tree
on ARM"
People: Russell King, Linus Torvalds, Tony Luck, Eli Carter, Alan Cox, Daniel
Jacobowitz, John Levon, John Bradford

Russell King said:

    This patch allows modules to work in Linus' tree for ARM, and is the one
    thing which prevents Linus' tree from building for any ARM machine.
   
    After reviewing the /proc/kcore and kclist issues, I've decided that I'm no
    longer prepared to even _think_ about supporting /proc/kcore on ARM - it
    just gets too ugly, and adds too much code to make it worth the effort, the
    time or the energy to implement a solution to that problem. This is
    especially true since most people use kgdb or similar rather than /proc/
    kcore anyway. /proc/kcore is a "wouldn't it be nice" feature.
   
    The reasons that I'm going with this solution rather than fixing /proc/
    kcore is that:
   
      + to add a kclist entry for each module would mean hacking the kclist
        structure into vm_struct's ->page pointer with disgusting hacks. I
        think we can all agree that this isn't the way to go. The alternative
        is to create Yet Another Memory Allocator, and this isn't something I
        want to see in what is now an embedded architecture.
      + we'd need to find some way to dynamically reserve the virtual mapped
        memory regions for the kernel direct mapped RAM. Since ARM uses a
        generic memory initialisation implementation which handles contiguous
        and discontiguous memory, it doesn't lend itself well to the kclist
        approach, and I'm not about to add extra callbacks from init/main.c (so
        we have kmalloc available) just to support this.
   
    If someone _else_ wants to put the effort into fixing ARM modules to work
    nicely with /proc/kcore, be my guest - I'm just no longer interested in
    this problem space.
   
    Maybe in 2.7 a generic "reserve an area of memory in this region" function
    like __get_vm_area below is in order?
   
    Therefore, I'm providing a patch which adds the necessary changes to the
    core kernel code to make the current modules solution work for ARM.
   
Linus Torvalds suggested just removing /proc/kcore entirely. He said, "Does
anybody actually _use_ /proc/kcore? It was one of those "cool feature" things,
but I certainly haven't ever used it myself except for testing, and it's
historically often been broken after various kernel infrastructure updates, and
people haven't complained.."

John Bradford said he'd used it on a few rare occassions, to recover files that
had been in RAM when its application had crashed. Daniel Jacobowitz also said
he used /proc/kcore for debugging, though he said he'd much rather have kgdb in
the kernel. And Tony Luck from Intel disclaimed:

    I only fixed it up because someone at SGI complained that my ia64 kernel
    virtual space re-arrangements had broken it (even more ... it had never
    been right for ia64).
   
    Even now, it's still full of races (e.g. if you start gdb to look at /proc/
    kcore, then load or unload modules).
   
    Plus gdb doesn't really understand that kcore is a special file, so it
    caches values (read "jiffies" twice and notice that it doesn't change ...
    because gdb cached the read).
   
    So don't mistake my recent activity fixing kcore for interest in its
    continued existence.
   
Alan Cox urged Linus to put kgdb in the kernel, and added that he wouldn't mind
seeing /proc/kcore become arch-specific, or even go away altogether. Eli Carter
also said he'd like to see kgdb in the kernel.

John Levon said that /proc/kcore was the only way to figure out the kernel
pointer size from user-space, and he pointed out that all suggestions for how
to do it had objections listed in an earlier linux-kernel discussion (http://
marc.theaimsgroup.com/?t=104205635900001&r=1&w=2) . Russell summarized, 
"oprofile requires /proc/kcore support" . Linus said, "Why not just fix the
oprofile interfaces to contain that information? You already have to export CPU
type, buffer size etc.." John said he'd be happy to do that, but he'd been
under the impression that such a patch would be rejected as unnecessary bloat.
He whipped up a patch and posted it.

 

6. Development Strategy For Unmaintained Drivers
18 Aug  (12 posts) Subject: "Re: Fix up riscom8 driver to use work queues
instead of task queueing."
Topics: SMP
People: Russell King, Linus Torvalds

In the course of discussion, Russell King suggested that for older serial
drivers, the "correct approach is for someone to convert them to use the new
serial driver core (and fix the driver core interface to allow them to work
with it.)" He didn't have any of that hardware, but he'd been hoping for
someone who did to step up and fix them. Linus replied:

    Hey, I'm all for that for 2.7.x. In the meantime, they've been broken for a
    year, so let's just try to fix them up into a "limping along" state.
   
    I don't have the hardware either, but at least now they should be testable
    on UP configurations (SMP is generally still broken due to the drivers
    expecting to be able to disable all interrups globally instead of using
    proper locking).
   
    I'd be interested to hear whether the dang things work. Of course, there
    probably aren't that many people around with the hardware any more. I could
    just have added them to the BROKEN list, but since they _might_ work it
    seemed like a better idea to be hugely optimistic instead ;)
   
Russell replied, "True. However, there is the opposite point of view which is
equally valid. There aren't many people with the hardware, and the people that
there are aren't interested in development kernel series, so even if we did
convert them during 2.7, we wouldn't hear about it until 2.8." And Linus said:

    Yes. However, what worries me more is that there are people who have the
    hardware, but because the driver won't even compile for them, they just go
    "oh, well, I'll try it again when the _real_ 2.6.0 hits the streets".
   
    Which obviously won't work.
   
    So I'm trying to make sure that all the broken drivers are gotten to a
    working state. Right now, considering how long they've been broken, that
    means "it must compile" so that people can test them.
   
    The "leave it broken, so that somebody will fix it properly some day"
    approach is a fine one for early development series. But right now I'd
    prefer to see patches to make drivers compile cleanly, even if people can't
    test them on real hardware.
   
    The intersection of people who have the hardware, and people who have the
    time/knowledge to convert a driver, may be empty. Expecially for odd
    hardware. So let's get those drivers compiling, even if we can't test them,
    so that others _can_ test them.
   
 

7. New AEM (Asynchronous Event Mechanism) For Linux
20 Aug  (1 post) Subject: "[ANNOUNCE] Supporting asynchronous events in Linux
with AEM"
People: Frederic Rossi

Frederic Rossi announced:

    I'd like to announce the availability of AEM (async. event mech.). This
    project is an attempt to provide a generic and native support for
    asynchronous events in the Linux kernel.
   
    See below for an overview of AEM. More information can be found here http:/
    /aem.sourceforge.net
   
    Your comments are valuable and I will be pleased to get any feedback from
    you.
   
    Overview
   
    The primary objective of AEM is to provide a native kernel mechanism, which
    doesn't make use of other techniques to support the semantic. The reason
    behind this is to be able to handle a very huge number of events in a
    scalable and responsive way.
   
    Basically, AEM allows an application to register to system events by
    supplying user-space event handlers during registration. When an event
    occurs in the kernel the corresponding event handler is executed with the
    data in parameter.
   
    AEM is a communication mechanism more than a notification mechanism in the
    sense the main goal is really to pass information quickly from the kernel
    to the user space applications, both ways. This means the data can be
    modified by event handlers and be re-interpreted when back into the kernel.
   
    The second goal behind AEM is to provide the atomic execution of user space
    handlers directly in reaction to events. Priorities can be associated with
    events to give high priority events the possibility to boost their
    corresponding processes. As opposed to other styles of event monitoring
    mechanisms AEM is working bottom-up, i.e user processes are executed/
    created by system events.
   
    Generally, we assume that event handlers are short lived executing quickly
    in the same execution context as the calling process. But if necessary an
    event handler can also be executed inside a new process context permitting
    its execution in parallel with the main thread of execution. In this case,
    processes are created on the fly.
   
    I'm taking special care to integrate AEM with existing mechanisms providing
    similar, although different, functionalities. I want to stress the fact
    that the goal of AEM is not to replace what already exist but to provide a
    complementary support in Linux.
   
    I'm conscious the current implementation is not perfect and a lot of work
    is still to be done. Any suggestion for improvement is welcome.
   
    Current status
   
    Specific structures and activation points for events must be present in the
    kernel. This is implemented by a patch supplying this basic infrastructure.
   
    The whole implementation is provided by independent kernel modules. One
    module supplies the core functionalities while the other modules supply
    specific implementations of event handling mechanisms (fetching and
    handling of data). Also, definitions of the calling APIs are implemented by
    modules.
   
    This architecture is very flexible. Different implementations can coexist
    in the same time. This gives the possibility to stay compatible in case of
    a change of API or semantics.
   
    AEM is currently supported on Linux kernels 2.6.0-test1 and 2.4.20.
   
 

8. FUSD v1.10 Released
20 Aug  - 21 Aug  (2 posts) Subject: "[ANNOUNCE] FUSD v1.10 now available"
Topics: FS: devfs, Real-Time, SMP
People: Jeremy Elson

Jeremy Elson announced FUSD v1.10 (http://www.circlemud.org/~jelson/software/
fusd) :

    We're happy to announce release 1.10 of FUSD, the Linux Framework for
    User-Space Devices.
   
    If you have a Linux 2.4 kernel running devfs, FUSD is a combination of
    Linux kernel module and userspace library that lets you write userspace
    programs that can act as character device drivers for files under /dev.
    Your program reigsters the device with the kernel module; then, it proxies
    system calls (e.g., open(), read()...) to your program. Your userspace
    program can respond to these system calls as a kernel module would. Strict
    error checking at the user/kernel boundary prevents such userspace drivers
    from corrupting each other, the kernel, or even the processes using the
    devices they manage.
   
    v1.10 has a number of enhancements, including:
   
      + Now safe for SMP and preemptible kernels
      + Includes both C and Python bindings
      + /dev/fusd/status device shows a summary of devices registered and in
        use
      + Updated documentation and various other bugfixes
   
    Unfortunately, FUSD does NOT work under later 2.5 or any 2.6 kernels. The
    recent changes to the devfs API break FUSD in a way that we haven't yet
    looked into fixing.
   
 

 

 

 

 

 

                       We Hope You Enjoy Kernel Traffic                        
                                                                               

 Kernel Traffic is hosted by the generous folks at Tux.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.