Kernel Traffic #190 For 28 Oct 2002

By Zack Brown

Table Of Contents

Mailing List Stats For This Week

We looked at 1448 posts in 8731K.

There were 440 different contributors. 231 posted more than once. 231 posted last week too.

The top posters of the week were:

1. High Resolution Timers

9 Oct 2002 - 18 Oct 2002 (26 posts) Archive Link: "[PATCH 2/3] High-res-timers part 2 (x86 platform code) take 5.1"

Topics: POSIX, Power Management: ACPI

People: George AnzingerLinus TorvaldsRobert LoveJim HoustonRandy Dunlap

George Anzinger posted a patch and explained:

This patch, in conjunction with the "core" high-res-timers patch implements high resolution timers on the i386 platforms. The high-res-timers use the periodic interrupt to "remind" the system to look at the clock. The clock should be relatively high resolution (1 micro second or better). This patch allows configuring of three possible clocks, the TSC, the ACPI pm timer, or the Programmable interrupt timer (PIT). Most of the changes in this patch are in the arch/i386/time.c code.

This patch uses (if available) the APIC timer(s) to generate 1/HZ ticks and sub 1/HZ ticks as needed. The PIT still interrupts, but if the APIC timer is available, just causes the wall clock update. No attempt is made to make this interrupt happen on jiffie boundaries, however, the APIC timers are disciplined to expire on 1/HZ boundaries to give consistent timer latencies WRT to the system time.

With this patch applied and enabled (at config time in the processor feature section), the system clock will be the specified clock. The PIT is not used to keep track of time, but only to remind the system to look at the clock. Sub jiffies are kept and available for code that knows how to use them.

Linus Torvalds was skeptical, remarking, "I really don't get the notion of partial ticks, and quite frankly, this isn't going into my tree until some major distribution kicks me in the head and explains to me why the hell we have partial ticks instead of just making the ticks shorter."

A lot of people spoke up. Randy Dunlap said that Carrier Grade Linux, while not an actual distribution, did use George's patches; and urged Linus to accept them. Robert Love added, "Linus, please consider merging at least George's latest patch set which provides just the new system calls to support POSIX clocks and timers. There is no dependence on the high-resolution bits, so at least Linux can provide the missing POSIX.4 system calls. George can then provide the high resolution code separately which can be debated and optionally merged."

Elsewhere, Jim Houston added that Concurrent had been using the patches, and would like to see them in the main tree; and added, "To answer the partial tick question, it's a trade off. If all you need is 1 milli-second resolution, it might not be worth spliting the tick. It's a question of how the overhead to set up a timer compares to the overhead of the higher frequency tick interrupts. If you want micro-second resolution, you need to split the tick. This is important to folks doing control systems. They get excited about timing jitter and resolution. It is also interesting to folks doing games. It's nice to be able to do short delays by blocking rather than having to spin in a delay loop."

Also in reply to Linus, George explained:

the notion is to provide timers that have resolution down into the micro seconds. Since this take a bit more overhead, we just set up an interrupt on an as needed basis. This is why we define both a high res and a low res clock. Timers on the low res clock will always use the 1/HZ tick to drive them and thus do not introduce any additional overhead. If this is all that is needed the configure option can be left off and only these timers will be available.

On the other hand, if a user requires better resolution, s/he just turns on the high-res option and incures the overhead only when it is used and then only at timer expire time. Note that the only way to access a high-res timer is via the POSIX clocks and timers API. They are not available to select or any other system call.

Making ticks shorter causes extra overhead ALL the time, even when it is not needed. Higher resolution is not free in any case, but it is much closer to free with this patch than by increasing HZ (which, of course, can still be done). Overhead wise and resolution wise, for timers, we would be better off with a 1/HZ tick and the "on demand" high-res interrupts this patch introduces.

2. Hard-To-Track Bugs Caused By Obscure Global Symbols

14 Oct 2002 - 18 Oct 2002 (21 posts) Archive Link: "unhappy with current.h"

Topics: Debugging

People: Daniele LugliAndi KleenMikael PetterssonAlexander ViroDavid S. MillerRik van RielChris Wedgwood

Daniele Lugli discovered a strange reserved-word situation in the kernel, when he tried to name one of the fields of a struct in her module, 'current'. After several days of anguished hunting, he tracked the problem down to asm/current.h, indirectly included in his module. This file contained the line '#define current get_current()'. The result was that "my structure becomes the owner of a function it has never asked for, while it looses a data member. gcc has nothing to complain about that." He suggested that #defines should be minimized in the kernel, to avoid this kind of obscure bug.

David S. Miller replied hard-nosedly, that a better solution would be to avoid using member names that conflict with established global symbols. Elsewhere, Andi Kleen suggested:

How about changing the definition to:

#define current ((struct task_struct *)get_current())

That should get the same effect as currently for kernel code, but will guarantee a syntax error if it's used in a structure declaration.

Elsewhere, Chris Wedgwood suggested that Daniele try compiling with 'gcc -Wshadow', which would also catch the error at compile time. Rik van Riel suggested adding that flag to the standard tree; and there was some support for this. But Mikael Pettersson pointed out that Daniele's problem had been caused specifically by her use of the C++ compiler instead of the normal C compiler. He added, "I fail to see the utility of hacking in kludges for something that's not supposed to work anyway." Daniele admitted she was indeed writing a kernel module in C++, but added, "let me at least summarize my poor-programmer-not-kernel-developer point of view: at present the kernel if a mined field for c++ and i understand it is not viable nor interesting for the majority to rewrite it in a more c++-friendly way. But why not at least keep in mind, while writing new stuff (not the case of current.h i see), that kernel headers could be included by c++?" Alexander Viro replied:

current.h is, indeed, a special case. #define i j would not be tolerated simply because it's stupid. Abuses of preprocessor are generally frowned upon, but there are passionate wa^H^Hpersons who just can't help themselves and use e.g. ## for no good reason.

But as for C++... frankly, for all I care it doesn't exist. As long as requirements of style happen to reduce problems of C++ programmers - they are lucky. But other than that... watch me not care. In the linux kernel context C++ is obscure language and it will stay that way. Ergo, no reasons to spend any mental efforts on being nice to it. Deal.

3. Major UNIXism Deprecated: FS Interfaces Preferred Over ioctls

15 Oct 2002 - 18 Oct 2002 (17 posts) Archive Link: "[PATCH] Device-mapper submission 6/7"

Topics: FS: ramfs, Ioctls

People: Jeff GarzikGreg KHJoe Thornber

Joe Thornber posted a patch that included some new ioctls, and Jeff Garzik said, "If you're adding a new interface, there should be no need to add new ioctls and all that they entail. Just control via a ramfs-based fs..." Greg KH agreed, and added, "With libfs now in 2.5, it's quite easy to make such a filesystem."

4. Patent Problems Around IPMI Driver

15 Oct 2002 - 22 Oct 2002 (6 posts) Subject: "[PATCH] IPMI driver for Linux, version 7"

Topics: Patents, USB

People: Corey MinyardAdrian BunkPeter ChubbInaky Perez-GonzalezAlan CoxArjan van de Ven

Corey Minyard announced version 7 of the IPMI driver ( , saying, "cleanups and bug fixes, some from Arjan van de Ven, and others from myself. This fixes some problems with blocking operations while holding a lock. It has an unfortunate interface change (but better now than later), the lun field is removed from the IPMI message, and one is added to the system interface address. It's a minor change, but it really needed to be done to make things consistent. It's only released as a patch to the v6 version and it applies cleanly to all kernel versions. As usual, you can download the driver from my home page at"

Adrian Bunk pointed out that anyone implementing IPMI, IPMB, or ICMB, had to sign a patent license, which included the text, "Adopter hereby grants to the Promoters and to Fellow Adopters, and the Promoters hereby grant to Adopter, a nonexclusive, royalty-free, nontransferable, nonsublicenseable, worldwide license under its Necessary Claims to make, have made, use, import, offer to sell and sell products which comply with the Specification; provided that such license shall not extend to features of a product which are not required to comply with the Specification or for which there exists a feasible, noninfringing alternative." He asked, "Am I right that this makes it impossible to include an IPMI driver into the kernel (this isn't GPL-compatible)?" Corey replied, "I do not read it so, but perhaps you are right. I will ask. I'm sure I will receive a resounding "maybe" as the answer. I was working with people at Intel on this, and they had another driver they wanted to use for IPMI, and wanted to push it into the kernel, but it had some problems so I wrote this as a replacement. So I don't think Intel sees it this way (at least those at Intel I was working with)."

Peter Chubb said, "I suspect the licence refers to the firmware bottom half, not the driver to access it." Alan Cox asked someone from Intel to clarify the situation, and Inaky Perez-Gonzalez from Intel replied (not actually speaking for Intel), "Corey's IPMI driver is GPL, as are all the other components of the kernel. People who are worried about patents on IPMI implementations can get a royalty-free license any time by going to and signing the Adopter's agreement. Yes, to get the royalty-free patent license for implementations of the IPMI spec, you have to give a promise not to sue other Adopters of IPMI, but I don't see why anyone who isn't planning on going around suing people should have a problem signing this agreement. In any case this is very similar to USB, which also has an Adopter's agreement for patents, and USB has been in the kernel for years without causing any IP problems."

5. Linux 2.5.43 Released

15 Oct 2002 - 19 Oct 2002 (31 posts) Subject: "Linux v2.5.43"

Topics: Disks: IDE, Disks: SCSI, Feature Freeze, Ioctls

People: Linus TorvaldsBill DavidsenShawn Leas

Linus Torvalds announced 2.5.43 ( , and said:

A huge merging frenzy for the feature freeze, although I also spent a few days getting rid of the need for ide-scsi.c and the SCSI layer to burn CD-ROM's with the IDE driver (it still needs an update to cdrecord, I sent those off to the maintainer).

The most fundamental stuff is probably RCU and oprofile, but there's stuff all over the map here..

Bill Davidsen remarked, "I hope you haven't broken running WITH ide-scsi, because most people still run 2.4 kernels in real life and only test 2.5 because someone has to do it. Reconfiguring the system to use ide-scsi or not is just one more PITA thing which needs to be done, or more likely forgotten, with every new kernel." Shawn Leas felt it would be fine to break the old stuff, since a single kernel argument or modification of /etc/modules.conf would solve any problems that might crop up. Bill was not in favor of that, and Linus replied to Shawn:

Anyway, ide-scsi should work as well as it ever did, which is not to say too well. It's just that the IDE native implementation is cleaner and simpler, and a _hell_ of a lot easier to use.

The scsi-generic layer is a total nightmare. If you want to write to the device that is /dev/scd0, you can't just use /dev/scd0, you have to use the right /dev/sgX, and the X depends on how many disks etc you have in the system and where your controller is. The amount of crap you have to do with things like "cdrecord -scanbus" to just figure out what the right device is is just ludicrous.

With the native IDE setup, if your CD is /dev/hdc, then that's what you use for cdburning too. Just do "cdrecord dev=/dev/hdc" and that's it. No made-up SCSI bus numbers, no need to try to figure out what the right thing is, no crap.

In fact, I hope that in linux-2.7.x the SCSI layer itself will start using the same interface, so that we can drop scsi-generic some day completely. The interface is totally generic, and doesn't have anything to do with IDE per se - ide-cd.c just needed to be cleaned up enough to be able to use it. The interface really just says "hey, you can push SCSI commands down the request queue" (and ide-cd.c will take the SCSI command and convert it into an ATAPI packet command - which is a pretty trivial transform).

So right now, you can do "cdrecord dev=/dev/hdc ..", but because I didn't bother to try to figure out what the SCSI layer wants to do you can _not_ do the simple "cdrecord dev=/dev/scd0 .." if you have a SCSI disk. That's nothing fundamental, I just don't think SCSI CD-RW's are very interesting any more, since they are overpriced and hard to find. I hope some SCSI fanatic will do the (probably trivial) addition to sr.c to accept the SCSI ioctl interface.

(Hint for such SCSI users: you should just do:

and that should be pretty much it).

Elsewhere, Bill reported his own experience, "I'm happy to report that ide-scsi is still working fine, both for CD, CD-RW and ZIP drives. Which makes life nice on a system with both ATAPI and SCSI CD devices, since my scripts need only get the bus and id, not use another device name format."

6. Maintainers List

16 Oct 2002 - 18 Oct 2002 (2 posts) Archive Link: "lk maintainers"

Topics: Bug Tracking, Disk Arrays: RAID, Disks: IDE, Disks: SCSI, FS: NFS, FS: NTFS, FS: ReiserFS, FS: autofs, FS: devfs, FS: ext2, FS: ext3, FS: smbfs, Framebuffer, Hot-Plugging, I2O, Networking, PCI, Real-Time: RTLinux, Samba, Serial ATA, Software Suspend, Sound: ALSA, Spam, USB, Virtual Memory

People: Denis VlasenkoTrond MyklebustJan KaraArnaldo Carvalho de MeloAlexander ViroHans ReiserRik van RielLinus TorvaldsVojtech PavlikGeert UytterhoevenAndre HedrickJeff GarzikGreg KHJaroslav KyselaAnton AltaparmakovTigran AivazianMartin J. BlighArjan van de VenEric S. RaymondMike PhillipsOleg DrokinH. Peter AnvinAlan CoxPavel MachekDave JonesRichard GoochAndrew MortonJens AxboeJames SimmonsIngo MolnarVictor YodaikenTim WaughRusty RussellGerd KnorrAndrea ArcangeliMartin DaleckiDavid S. MillerJan-Benedict GlawRogier WolffUrban WidmarkPaul LarsonPetr VandrovecMarcelo TosattiNeil BrownRussell KingRalf BaechleRobert LoveMaksim KrasnyanskiyStuart MacDonald

Denis Vlasenko posted his latest list of kernel maintainers:

So, you are new to Linux kernel hacking and want to submit a kernel bug report or a patch but don't know how to do it and _where_ to report it?

Preparing bug report:
*** Remember: bad/incomplete bug report ONLY wastes bandwidth! ***
How To Ask Questions The Smart Way:
        Anybody who has written software for public use will
        probably have received at least one bad bug report.
        Reports that say nothing ("It doesn't work!");
        reports that make no sense; reports that don't give
        enough information; reports that give wrong information.
How to Report Bugs Effectively:
        Before asking a technical question by email, or in
        a newsgroup, or on a website chat board, do the following:
        * Try to find an answer by searching the Web.
        * Try to find an answer by reading the manual.
        * Try to find an answer by reading a FAQ.
        * Try to find an answer by inspection or experimentation.
        * Try to find an answer by reading the source code.
Compile problems: report GCC output and result of "grep '^CONFIG_' .config"
Oops: decode it with ksymoops.
Unkillable process: Alt-SysRq-T and ksymoops relevant part.
Yes it means you should have ksymoops installed and tested,
which is easy to get wrong. I've done that too often.

Sending bug report/patch:
* Some device drivers have active developers, try to contact them first.
* Otherwise find a subsystem maintainer to which your report pertains
  and send report to his address.
* Small fixes and device driver updates are best directed to subsystem
  maintainers and "small bits" integrators.
* It never hurts to CC: Linux kernel mailing list, but without specific
  maintainer address in To: field there is high probability that your
  patch won't be noticed. You have been warned.
* Do not send it to all addresses at once! This will annoy lots of people
  and isn't useful at all. It's a spam.
* Do NOT send small fixes to Linus, he just can't handle _everything_.
  He will eventually receive it from maintainers/integrators, send it
  their way.
* If your patch is something big and new, announce it on lkml and try
  to attract testers. After it has been tested and discussed, you can
  expect Linus to consider inclusion in mainline.

                Current Linux kernel people

Note that this list is sorted in reversed date order, most recent
entries first. This means than entries at bottom can be outdated :-(

Linux kernel mailing list <>
        Post anything related to Linux kernel here, but nothing else :-)

Andre Hedrick <> [02 oct 2002]
        ATA/ATAPI Storage Architect [2.0,2.2,2.4,2.5]
        HBA interface developer
        Serial ATA Architect [future release]
        Voting NCITS member AT-Attachment Committee

Jeff Garzik <> [24 sep 2002]
        I am the network-card-drivers guy (8139 for instance).
        CC me and Andrew Morton <> on network driver patches.

Jan-Benedict Glaw <> [18 sep 2002]
        I'm responsible for Alpha's srm_env driver, providing access to
        SRM's firmware variables.

Stuart MacDonald <> [13 sep 2002]
        Connect Tech's linux kernel guy. Currently includes hacking on
        drivers/char/serial.c (Blue Heat, Xtreme, Dflex) and maintaining
        drivers/usb/serial/whiteheat.c (WhiteHEAT)

Vojtech Pavlik <> [13 sep 2002]
        Feel free to send me bug reports and patches to input device drivers
        (drivers/input/*, drivers/char/joystick/*)
        I also want to receive bug reports and patches for following
        USB drivers: printer, acm, catc, hid*, usbmouse, usbkbd, wacom.
        All other (not in the list) USB driver changes should go to USB
        maintainer (hopefully there is one listed here :-).
        Also CC me if you are posting VIA IDE driver related message
        (although I am not IDE subsystem maintainer).

Robert Love <> [12 sep 2002]
        Preemptible kernel maintainer.
        I am also interesting in anything related to scheduling or locking

Jan Kara <> [22 aug 2002]
        quota subsystem maintainer

Paul Larson <> [20 aug 2002]
        I'm a maintainer for the Linux Test Project and it would be nice
        if people knew to send their test programs, etc. to me.  I see
        a lot of them flying around on lkml and try to catch them when
        I can, but it's a lot to keep up with.  It would be even better
        if people just knew to send them our way so we could clean
        them up and put them in LTP for regression testing.

Dave Engebretsen <> [15 aug 2002]
        PPC64 architecture maintainer.  Please send PPC64 patches to me
        and our mailing list at <>

Ingo Molnar <> [30 jul 2002]
        Ingo wrote the new scheduler for 2.5.

Ralf Baechle <> [30 jul 2002]
        I am maintainer of the AX.25 code

Victor Yodaiken <> [30 jul 2002]
        RTLinux patches, updates, contributions, drivers.
        Please send first to the list:

Pavel Machek <> [27 jul 2002]
        I am network block device maintainer. Visit
        (see Steven Whitehouse <> entry)
        I am working on software suspend.

William Irwin <> [02 jul 2002]
        Send bug reports and/or feature requests related to many tasks,
        rmap, space consumption, or allocators to me. I'm involved in
        * rmap
        * memory allocators
        * reducing space consumed by data structures (e.g. struct page)
        * issues arising in workloads with many tasks
        * kernel janitoring
        See also:
        Rik van Riel <>
        Andrea Arcangeli <>
        Martin Bligh <>
        Andrew Morton <>

Dave Jones <> [23 apr 2002]
        I collect various bits and pieces for inclusion in 2.5,
        especially small and trivial ones and driver updates.
        I'll feed them to Linus when (and if) they
        are proved to be worthy.

Andrea Arcangeli <> [28 mar 2002]
        Send VM related bug reports and patches to me.
        I'm especially interested in VM issues with:
        * lots of RAM and CPUs
        * NUMA
        * heavy swap scenarios
        * performance of I/O intensive workloads (in particular
          with lots of async buffer flushing involved)
        See also Martin J. Bligh <> entry
        Mail also:
        Arjan van de Ven <>

Martin J. Bligh <> [28 mar 2002]
        I'm interested in VM issues with lots (>4G for i386)
        of RAM, lots of CPUs, NUMA

Steven Whitehouse <> [27 mar 2002]
        I am the Linux DECnet network stack maintainer

Arnaldo Carvalho de Melo <> [26 mar 2002]
        IPX, 802.2 LLC, NetBEUI,,
        cyclom2x sync card driver

John Cagle <> [19 mar 2002]
        The current maintainer of devices.txt, the list of
        assigned device numbers for LANANA.  Consult the web
        site ( for instructions on submitting
        requests for new device numbers.  Send all device
        related email to <>.

Tigran Aivazian <>
        I am author and maintainer of BFS filesystem and IA32
        microcode update driver.

Rogier Wolff <> [12 mar 2002]
        I do "specialix serial ports":
        drivers/char/specialix.c (IO8+)
        drivers/char/sx.c        (SX, SI, SIO)
        drivers/char/rio/*.c     (RIO)

Martin Dalecki <> [11 mar 2002]
        IDE subsystem maintainer for 2.5
        (mail Vojtech Pavlik <> too)

Ed Vance <> [05 mar 2002]
        Maintainer for the generic serial driver, serial.c,
        for 2.2 and 2.4 kernels.  Please post patches to for tested bug
        fixes or to add support for a new serial device.
        Limited to time available. If I have not responded
        in a week, yell at

netfilter/iptables development <> [23 feb 2002]
        Please report all netfilter/iptables related problems
        to this mailinglist, where all netfilter developers are present.
        See also

Hans Reiser <> [16 feb 2002]
        Send me all reiserfs related patches with a cc to, send bug reports to, send paid support requests to after going to
        to pay, send discussions (not bug reports unless they are
        interesting to most persons) to
        If we sit on your patch for a week without responding,
        yell at us, we deserve it.  Look at our web page
        at for more about sending us code,
        working with us, and our patch submission and tracking system.

Paul Bristow <> [16 feb 2002]
        I am an ide-floppy driver maintainer
        (ATAPI ZIP, LS-120/240 Superdisk, Clik! drives).

Mike Phillips <> [15 feb 2002]
        Token ring subsystem and drivers.

Anton Altaparmakov <> [15 feb 2002]
        I am the NTFS guy. [14 feb 2002]
        Reports of problems with the Red Hat shipped kernels.

Alan Cox <> [14 feb 2002]
        Linux 2.2 maintainer (maintenance fixes only).
        Collator of patches for unmaintained things in 2.2/2.4.
        Maintainer of the 2.4-ac (2.4 plus stuff being tested) tree.
        I2O, sound, 3c501 maintainer for 2.2/2.4.

ALSA development <> [12 feb 2002]
Jaroslav Kysela <> [12 feb 2002]
        Advanced Linux Sound Architecture
        ALSA patches are available at* (

Neil Brown <> [08 feb 2002]
        I am interested in any issues with the code in:
        NFS server    (fs/nfsd/*)
        software RAID (drivers/md/{md,raid,linear}*)
        or related include files.

Maksim Krasnyanskiy <> [08 feb 2002]
        I'm author and maintainer of the Bluetooth subsystem
        and Universal TUN/TAP device driver.
        These days mostly working on Bluetooth stuff.

Rik van Riel <> [07 feb 2002]
        Send me VM related stuff, please CC to

Geert Uytterhoeven <> [07 feb 2002]
        I work on the frame buffer subsystem, the m68k port (Amiga part),
        and the PPC port (CHRP LongTrail part).
        Unfortunately I barely have spare time to really work on these
        things. My job is not Linux-related (so far :-). I can not
        promise anything about my maintainership performance.

H. Peter Anvin <> [07 feb 2002]
        i386 boot and feature code, i386 boot protocol, autofs3,
        compressed iso9660 (but I'll accept all iso9660-related
        changes). site manager; please contact me
        for sponsorship-related issues. admins <> [07 feb 2002] sysadmins.  Contact us if you notice something breaks,
        or if you want a change make sure you give us at least 1-2 weeks.
        Please note that we got a lot of feature requests, a lot of
        which conflict or simply aren't practical; we don't have time to
        respond to all requests.

Greg KH <> [07 feb 2002]
        I am USB and PCI Hotplug maintainer.

Trond Myklebust <> [07 feb 2002]
        I am NFS client maintainer.

James Simmons <> [07 feb 2002]
        Console and framebuffer sybsustems.
        I also play around with the input layer.

Richard Gooch <> [07 feb 2002]
        I maintain devfs. I want people to Cc: me when reporting devfs
        problems, since I don't read all messages on linux-kernel.
        Send devfs related patches to me directly, rather than
        bypassing me and sending to Linus/Marcelo/Alan/Dave etc.

Russell King <> [06 feb 2002]
        ARM architecture maintainer.  Please send all ARM patches through
        the patch system at
        New serial drivers maintainer for 2.5.  Submit patches to

Andrew Morton <> [05 feb 2002]
        I'm receptive to any reproducible bug anywhere in the 2.4 kernel.
        Specialising in ext2, ext3 and network drivers.
        Not thinking about 2.5.x at this time.

Petr Vandrovec <> [05 feb 2002]
        ncpfs filesystem, matrox framebuffer driver, problems related
        to VMware - in all of 2.2.x, 2.4.x and 2.5.x.

Reiserfs developers list <> [05 feb 2002]
        Send all reiserfs-related stuff here including but not limited to bug
        reports, fixes, suggestions.

Oleg Drokin <> [05 feb 2002]
        SA11x0 USB-ethernet and SA11x0 watchdog are mine.

======= These entries are suggested by lkml folks ========

Ralf Baechle <> [27 mar 2002]
        I am mips/mips64 maintainer.

David S. Miller <> [07 feb 2002]
        I am Sparc64 and networking core maintainer.

======= These ones I made myself ========
======= I am waiting confirmation/correction from these people ========

Urban Widmark <> [13 feb 2002]

video4linux list <> [12 feb 2002]
Gerd Knorr <> [12 feb 2002]

Tim Waugh <> [08 feb 2002]
        > Who is maintaining the linux iomega stuff?
        For 2.4.x, me (in theory). I don't have time for 2.5.x at the moment.

Alexander Viro <> [5 feb 2002]
        I am NOT a fs subsystem maintainer. But I won't kill
        you if you send me some generic fs bug reports and (hopefully) patches.

Eric S. Raymond <> [5 feb 2002]
        Send kernel configuration bug reports and suggestions to me.
        Also I'll be more than happy to accept help enties for kernel config
        options (

G?rard Roudier <> [5 feb 2002]
        I am SCSI guy.

Jens Axboe <> [5 feb 2002]
        I am block device subsystem maintainer.

Linus Torvalds <> [5 feb 2002]
        Do not send anything to me unless it is for 2.5, well tested,
        discussed on lkml and is used by significant number of people.
        In general it is a bad idea to send me small fixes and driver
        updates, send them to subsystem maintainers and/or
        "small stuff" integrator (currently Dave Jones <>,
        see his entry). Sorry, I can't do everything.

Marcelo Tosatti <> [5 feb 2002]
        Do not send anything to me unless it is for 2.4 and well tested.
        If you are sending me small fixes and driver updates, send
        a copy to subsystem maintainers and/or "small stuff" integrators:
        - Alan Cox <>,
        - Rusty Russell <>.

Rusty Russell <> [5 feb 2002]
        > Here are some cleanups of whitespace in .....
        Want me to add this to the trivial patch collection for tracking?
        If so just send (or cc:) it to

James Simmons pointed out that his new email address was

7. New Linux Security Project

16 Oct 2002 - 18 Oct 2002 (2 posts) Archive Link: "Linux Security Protection System"

Topics: FS

People: Bosko RadivojevicJakob Oestergaard

Bosko Radivojevic announced:

LinSec team is proud to announce first stable release of LinSec.

LinSec, as the name says, is Linux Security Protection System. The main aim of LinSec is to introduce Mandatory Access Control (MAC) mechanism into Linux (as opposed to existing Discretionary Access Control mechanism). LinSec model is based on:

As for Capabilities, LinSec heavily extends the Linux native capability model to allow fine grained delegation of individual capabilities to both users and programs on the system. No more allmighty root!

Filesystem Access Domain subsystem allows restriction of accessible filesystem parts for both individual users and programs. Now you can restrict user activities to only its home, mailbox etc. Filesystem Access Domains works on device, dir and individual file granularity.

IP Labeling lists enable restriction on allowed network connections on per program basis. From now on, you may configure your policy so that no one except your favorite MTA can connect to remote port 25

Socket Access Control model enables fine grained socket access control by associating, with each socket, a set of capabilities required for a local process to connect to the socket.

LinSec consists of two parts: kernel patch (currently for 2.4.18) and userspace tools.

Detailed documentation, download & mailing list information -

Jakob Oestergaard asked Bosko to describe how LinSec differed from SELinux; but there was no reply.

8. kexec Update For 2.5

17 Oct 2002 - 18 Oct 2002 (2 posts) Archive Link: "kexec for 2.5.42"

Topics: Ioctls, Kexec

People: Eric W. BiedermanWerner Almesberger

Eric W. Biederman announced:

O.k. My first pass at getting up to date with the current kernel is available at:

The big changes are:

  1. I have rebundled my tools so it is a little easier to get at:
  2. I have included a test case kexec_test that tests the stranger cases, so when the kernel doesn't boot, we can rule out the kexec code.
  3. I have added a call to device_shutdown so device drivers get a chance to shut up.
  4. I have moved kexec into its one system call instead of treating sys_reboot like an ioctl. The big reason is that while there is a lot of generic code some very architecture specific code must be written for each architecture, and having to register a system call means the code won't become active by accident.

I will probably split this up before sending to Linus but anyway, here is the patch so you can pick it apart and tell me what you don't like.

Werner Almesberger exclaimed, "Yipee! I was already having nightmares that we'd have to live without it for another major kernel release cycle. I had a quick glance at it, and it looks quite lovely."

9. Thread-Aware Coredumps In 2.5

17 Oct 2002 - 21 Oct 2002 (24 posts) Archive Link: "[patch] thread-aware coredumps, 2.5.43-C3"

Topics: Executable File Format, SMP, Version Control

People: Ingo MolnarUlrich Drepper

Ingo Molnar said:

the attached patch is the second iteration of thread-aware coredumps, against BK-curr. I think this patch is now ready for inclusion into mainline.


the IA64 ELF bits are not included, yet, to reduce complexity of the patch. The patch has been tested on x86 UP and SMP.

10. CSA System Resource Accounting Tool

17 Oct 2002 - 21 Oct 2002 (14 posts) Archive Link: "[PATCH] 2.5.43 CSA, Job, and PAGG"

People: John Hesterberg

John Hesterberg announced:

2.5.43 versions of CSA, Job, and PAGG patches are available at:

The CSA and job user-level code is in the same directories.

CSA (Comprehensive System Accounting) provides methods for collecting per-process resource usage data, monitoring disk usage, and charging fees to specific login accounts. CSA provides features which are not available with the other Linux accounting packages. For more information, see:

Linux Jobs is an inescapable process container that is typically created by point of entry processes like login, and inherited by children. PAGG (Process Aggregates) is a generic framework for implementing process containers such as Linux Jobs. For more information, see:

CSA depends on Linux Jobs, and Linux Jobs depends on PAGG.

Various folks had minor technical problems with the patch, such as typedef usage; but no serious objections were made.

11. Linux Kernel Book Recommendations

17 Oct 2002 - 21 Oct 2002 (7 posts) Archive Link: "Question: Favorite Linux kernel book?"

People: Ron HenryAlan CoxJonathan Corbet

Eric Altendorf asked which Kernel book folks liked best. Jonathan Corbet recommended Understanding The Linux Kernel ( and ia-64 Linux Kernel ( , as well as his own book, Linux Device Drivers (*&binding=*&isbn=0596000081&keywords=&minprice=&maxprice=&submit=Begin+Search&currency=USD&mode=advanced&st=sr&ac=qr) (also available for free at ( ). Ron Henry said, "I'd also recommend "Unix Internals: The New Frontiers ( ". The sections on memory management, particularly the slab allocator is worth understand seeing as how the linux's current slab allocator is based on the concepts discussed in that book." Alan Cox added, "If you are new to kernels and hardware the best book on Linux is in some ways Andy Tanenbaum's Operating Systems ( . Its not about Linux but its one of the best intros to the whole topic."

12. Generic AGP 3.0 Device Detection Support In 2.5

17 Oct 2002 - 18 Oct 2002 (3 posts) Subject: "[PATCH] GART driver support for generic AGP 3.0 device detection/ enabling & Intel 7505 chipset support"

People: Matthew E Tolentino

Matthew E Tolentino announced:

Attached is a patch for generic AGP 3.0 device detection and enabling routines as well as specific support for the Intel 7505 chipset against the 2.5.43 kernel.

This patch adds a new file agp3.c which contains generic enabling and detection routines based on the AGP 3.0 spec. Some of the new features include detection of multiple devices and proper isochronous bandwidth allocation to each discovered device, as well as the typical host bridge initialization. This patch also adds another file i7505-agp.c which contains the chipset specific support. It is prudent to note that this patch does not yet implement all of the capabilities defined by the AGP 3.0 spec.

13. Status Of Linux Trace Toolkit

17 Oct 2002 - 18 Oct 2002 (6 posts) Archive Link: "[ANNOUNCE] LTT 0.9.6pre2: Per-CPU buffers, TSC timestamps, etc."

People: Karim YaghmourFrank Rowand

Karim Yaghmour announced:

A new development version of LTT is now available, 0.9.6pre2. Here's what's new:

The release includes a patch for 2.5.43 which is pretty much ready for inclusion. I will be posting this patch raw ot the LKML with a more verbose description.

You will find 0.9.6pre2 here:

LTT's web site is here:

Cose by, he added, "0.9.6pre2 is a development version, it's expected to have rough spots." Elsewhere, Frank Rowand asked, "I noticed that the Linux 2.4.19 patch is not carried forward from pre1 to pre2. Are you planning to no longer maintain support for LTT in the Linux 2.4 line?" Karim replied:

The problem is that the kernel patch is highly dependent on the kernel's own development. The tracing infrastructure has to change as the kernel changes. Incidently, the user tools also have to change to accomodate the newer kernels. There's a point where keeping compatibility with older kernels becomes increasingly difficult and would entail one of two things:

Neither of these is really interesting. Of course, if someone wants to take the time to backport some of the new features to older kernels I would gladly publish their patch with the tools. The time it takes to work out an LTT patch is non-negligeable and I don't have the bandwidth to maintain multiple kernel patches in parallel. This is why I'm concentrating on getting LTT to work with the latest and greatest.

Obviously things will be much simpler once the LTT patch is included in the kernel.

14. JFS 1.0.24 Released

18 Oct 2002 (1 post) Archive Link: "[ANNOUNCE] Journaled File System (JFS) release 1.0.24"

Topics: FS: JFS, SMP

People: Steve Best

Steve Best announced:

Release 1.0.24 of JFS was made available today.

Drop 62 on October 18, 2002 (jfs-2.4-1.0.24.tar.gz and jfsutils-1.0.24.tar.gz) includes fixes to the file system and utilities.

Utilities changes

File System changes

For more details about JFS, please see the patch instructions or changelog.jfs files.

JFS for Linux

15. Voyager SMP Support For 2.5

18 Oct 2002 - 21 Oct 2002 (4 posts) Archive Link: "[PATCH] Voyager subarchitecture for 2.5.44"

Topics: SMP, Version Control

People: James BottomleyWilliam Lee Irwin IIIAlan Cox

James Bottomley announced:

This patch adds SMP (and UP) support for voyager which is an (up to 32 way) SMP microchannel non-PC architecture.

The current patch includes a swap around of the timer code defines (available separately at and a new CONFIG_X86_TRAMPOLINE config option to avoid the trampoline vpath.

The patch (156k) is available here:

And also via bitkeeper at

William Lee Irwin III remarked, "this patch is impressively isolated from generic i386 code. Although I've not tested, it seems very clear from the form of the code that it will have no impact on UP i386 or other subarches." Alan Cox mentioned that the patch had been in his -ac tree for a long time; while James also explained, "Well technically, there's the boot time GDT separation (make boot GDT smaller and simpler than the runtime) which affects all x86."

William had also asked, in his initia reply, "This is a very interesting architecture. Could you describe vaguely (for someone starved enough for time he might have trouble finding time to examine your tree) how cpu wakeup with the VIC proceeds?" And James replied:

You mean how the VIC boots? Certainly. Referring to the architecture in

The VIC is basically a set of 8258 dyads (and voyager has up to 8 of them). The boot CPU can send a cross processor interrupt (CPI) to any VIC connected CPU. However, the boot CPU can only modify its own VIC 8258 dyad, so theres a masquerade register that temporarily globally drives the VIC processor ID lines so that the boot CPU can lower the interrupt mask in a different VIC.

However, each CPU card has only one or two VIC connections, so booting the Quad cards is a sort of one-two trick: you VIC boot the VIC connected CPU (called the extended CPU) and then it QIC (Quad interrupt controller) boots the remaining CPUs. The QIC works using a cache line interference mechanism (so writes to a particular part of memory trigger the CPI). However, only CPUs local to the Quad can masquerade as each other to lower the QIC interrupt mask.

16. linux-2.5.44uc0 MMU-Less Kernel Released

19 Oct 2002 (1 post) Archive Link: "[PATCH]: linux-2.5.44uc0 (MMU-less support)"

Topics: Networking

People: Greg Ungerer

Greg Ungerer announced:

An updated uClinux patch is available at:


1. patched against 2.5.44

Smaller specific patches:

17. User-Mode Linux Updated To 2.5.44

19 Oct 2002 (1 post) Archive Link: "uml-patch-2.5.44-1"

Topics: FS, User-Mode Linux

People: Jeff Dike

Jeff Dike announced:

This patch updates UML to 2.5.44.

The only UML-specific change in this patch is the merge of some of James McMechan's ubd driver changes which make partitions work again.

The patch is available at

For the other UML mirrors and other downloads, see

Other links of interest:

The UML project home page :
The UML Community site :

18. Kernel 2.5.44-mm1 Released

20 Oct 2002 (2 posts) Archive Link: "2.5.44-mm1"

Topics: FS, SMP

People: Andrew Morton


Andrew Morton announced:


19. Patch Management Scripts

20 Oct 2002 (5 posts) Archive Link: "patch management scripts"

Topics: FS, Samba, Version Control

People: Andrew MortonOliver Xymoron

Andrew Morton said:

I finally got around to documenting the scripts which I use for managing kernel patches. See

These scripts are designed for managing a "stack" of patches against a rapidly-changing base tree. Because that's what I use them for.

I've been using and evolving them over about six months. They're pretty fast, and simple to use. They can be used for non-kernel source trees.

The implementation is pretty agricultural - I only know how to do three things in /bin/sh scripts and I'm not sure that I want to learn #4, but patches are accepted.

Hopefully these will be useful to some people. I'd expect that the ramp-up time is half an hour or so.

Here's the fine manual:

This is a description of a bunch of shell scripts which I use for
managing kernel patches.  They are quite powerful.  They can be used on
projects other than the linux kernel.  They are easy to use, and fast.

You end up doing a ton of recompiling with these scripts, because
you're pushing and popping all the time.  ccache takes away the pain of
all that. - be sure to put the cache
directory on the same fs as where you're working so that ccache can use

The key philosophical concept is that your primary output is patches.
Not ".c" files, not ".h" files.  But patches.  So patches are the
first-class object here.


All work occurs with a single directory tree.  All commands are invoked
within the root of that tree.  The scripts manage a "stack" of patches.

Each patch is a changeset against the base tree plus the preceding patches.

All patches are listed, in order, in the file ./series.  You manage the
series file.

Any currently-applied patches are described in the file
./applied-patches.  The patch scripts manage this file.

Each patch affects a number of files in the tree.  These files are
listed in a "patch control" file.  These .pc files live in the
directory ./pc/

Patches are placed in the directory ./patches/

Documentation for the patches is placed in ./txt/

So for a particular patch "my-first-patch" the following will exist:

- An entry "my-first-patch.patch" in ./series

- An entry "my-first-patch" in ./applied-patches (if it's currently applied)

- A file ./pc/my-first-patch.pc which contains the names of the
  files which my-first-patch modifies, adds or removes

- A file ./txt/my-first-patch.txt which contains the patch's

- A file ./patches/my-first-patch.patch, which is the output of the
  patch scripts.


When a patch "my-patch" is applied with apatch, or with pushpatch
(which calls apatch), all the affected files (from ./pc/my-patch.pc)
are copied to files with ~my-patch appended.  So if ./pc/my-patch.pc


then apatch will copy those files into kernel/sched.c~my-patch and
fs/inode.c~my-patch.  It will then apply the patch to kernel/sched.c
and fs/inode.c

When a diff is regenerated by refpatch (which calls mpatch), the diff
is made between kernel/sched.c and kernel/sched.c~my-patch.  How do the
scripts know to use "~my-patch"?  Because my-patch is the current
topmost patch.  It's the last line in ./applied-patches.

In this way, the whole thing is stackable.  If you have four patches
applied, say "patch-1", "patch-2", "patch-3" and "patch-4", and if
patch-2 and patch-4 both touch kernel/sched.c then you will have:

        kernel/sched.c~patch-2          Original copy, before patch-2
        kernel/sched.c~patch-4          Copy before patch-4.  Contains changes
                                        from patch-2
        kernel/sched.c                  Current working copy.  Contains changes
                                        from patch-4.

This means that your diff headers contain "~patch-name" in them, which
is convenient documentation.


Let's start.

Go into /usr/src/linux (or wherever)

        mkdir pc patches txt

Now let's generate a patch

        fpatch my-patch kernel/sched.c

OK, we've copied kernel/sched.c to kernel/sched.c~my-patch.  We've
appended "my-patch" to ./applied-patches and we've put "kernel/sched.c"
into the patch control file, pc/my-patch.pc.

        Now edit kernel/sched.c a bit.

Now we're ready to document the patch

        Now write txt/my-patch.txt

Now generate the patch


This will generate patches/my-patch.patch.  Take a look.

Now remove the patch


applied-patches is now empty, and the patch is removed.

Now let's add a file to my-patch and then generate my-second-patch:

        Add "my-patch.patch" to ./series (no blank lines in that file please)


OK, the patch is applied again.  Let's add another file

        fpatch kernel/printk.c

Note that here we gave fpatch a single argument.  So rather than
opening a new patch, it adds kernel/printk.c to the existing topmost
patch.  That's my-patch.

        Edit kernel/printk.c

Refresh my-patch (you end up running refpatch a lot)


Now start a second patch:

        fpatch my-second-patch kernel/sched.c

Now take a look at applied-patches.  Also do an `ls kernel/sched*'.

        Edit kernel/sched.c, to make some changes for my-second-patch

Generate my-second-patch:


Take a look in patches/my-second-patch.patch

Don't forget to add "my-second-patch.patch" to the series file.

And remove both patches:


That's pretty much it, really.

Command reference

Generally, where any of these commands take a "patch-name", that can be
of the form txt/patch-name.txt, patch-name.pc, just patch-name or
whatever.  The scripts will strip off a leading "/kernel-traffic/txt/index.html", "/kernel-traffic/patches/index.html" or
"/kernel-traffic/pc/index.html" and any trailing extension.  This is so you can do

        apatch patches/a<tab>

to conveniently use shell tabbing to select patch names.


  Some internal thing.

apatch [-f] patch-name

  This is the low-level function which adds patches.  It does the
  copying into ~-files and updates the applied-patches file.  It
  applies the actual patch.

  apatch will do a patch --dry-run first and will refuse to apply the
  patch if the dryrun fails.

  So when you are getting rejects you do this:

        pushpatch               # This fails, due to rejects.  Drat.
        apatch -f patch-name    # Force the patch

  OK, you've now applied patch-name, but you have rejects.  Go fix
  those up and do


  And you're ready to move on.


  I forget.

fpatch [patch-name] foo.c

  If patch-name is given, fpatch will start a new patch which
  modifies (or adds, or removes) the single file foo.c.  It updates
  ./applied-patches and creates pc/patch-name.pc.  fpatch will copy
  foo.c to foo.c~patch-name in preparation for edits of foo.c.

  If patch-name is not given then fpatch will add foo.c to the
  current topmost patch.  It will add "foo.c" to ./pc/$(toppatch).pc.
  It will copy foo.c to foo.c~$(toppatch).


  List the names of ths files which are affected by the current
  topmost patch.

  This is basically

        cat pc/$(toppatch).pc


  A low-level thing to generate patches


  Some thing I use for importing a new kernel from


  Internal thing to convert patch -p0 form into patch -p1


  Generates a single-line description of a patch.

  The txt/my-patch.txt files have the following format:

  <start of file>
  some short description

  The long description
  <end of file>

  I use

        patchdesc $(cat series)

  to generate short-form summaries of the patch series.


  Internal utilities


  Standalone tool to generate a .pc file from a patch.

  Say someone sends you "his-patch.diff".  What you do is:

        cp ~/his-patch.diff patches/his-patch.patch
        pcpatch his-patch

  This generates ./pc/his-patch.pc and you're all set.  Add
  "his-patch.patch" to ./series in the right place and start pushing.


  I forget


  Remove one or more patches fro the current stack.  This command
  does *not* use the series file.  It works purely against


                Remove the topmost patch
        poppatch 10
                Remove ten patches
        poppatch some-patch-name[.patch]
                Remove patches until "some-patch-name" is top patch


  Two modes:

        ptkdiff -

               Run tkdiff against all the file affected
               by $(toppatch).  The diff is only for the changes made
               by the top patch! ie: it's between "filename" and

        ptkdiff filename

               Just run tkdiff against that file,
               showing the changes which are due to toppatch.


  Apply the next patch, from the series file.

  This consults ./applied-patches to find out the top patch, then
  consults ./series to find the next patch.  And pushes it.


      Apply the next patch

    pushpatch 10

      Apply the next ten patches

    pushpatch some-patch-name

      Keep pushing patches until "some-patch-name" is toppatch


    regnerates the topmost patch.  Reads all the affected files
    from pc/$(toppatch).pc and diffs them against their tilde-files.

    Also pastes into the patch your patch documentation and
    generates a diffstat summary.


  Some thing.


  CVS rename for patches.


  Bit of a hack.  Is designed to generate a rolled-up diff of all
  currently-applied patches.  But it requires a ../linux-2.x.y tree to
  diff against.  Needs to be redone.


  Internal command


  Some thing someone write to split patches up.  I don't use it.


  Print the name of the topmost patch.  From ./applied-patches

touched-by-patch patch-filename

  List the names of files which are affected by a diff.

  Rasmus Andersen's script to convert a diff into minimum-context
  form.  This form has a better chance of applying if you're getting
  nasty rejects.  But patch can and will make mistakes when fed
  small-context input.

Work Practices

I keep the kernel tree, the ./pc/, ./patches/ and ./txt/ contents under
CVS control.  This is important...

I have several "series" files.  I keep these in ./pc/foo-series and use

        ln -s pc/foo-series series

when I'm working on foo.

If someone sends me a patch I'll do:

        cp ~/whatever patches/his-patch.patch
        pcpatch his-patch
        apatch his-patch

  If apatch fails then run `apatch -f his-patch' and fix the rejects.


  to clean up any fuzz.

        cvs add pc/his-patch.pc patches/his-patch.patch
        cvs commit pc patches

  Now edit ./series and place "his-patch.patch" in the appropriate place.

If you're working on a particular patch (say, "dud-patch") and you
balls something up, just run:

        refpatch        # Generate the crap patch
        poppatch        # Remove it all
        rm patches/dud-patch.patch
        cvs up patches/dud-patch.patch

and all is well.

Getting updates from Linus

What I do is to grab the latest -bk diff from
and do:

        gzip -d < cs<tab> > patches/linus.patch
        pcpatch linus
        apatch linus | grep diff

               Now fix up all the files which got deleted,
               because there's something wrong with bitkeeper diffs:

        cvs up -ko <missing files from the above diff>

        apatch linus
        $EDITOR linus/linus.txt

                Add the changeset number to txt/linus.txt


  Now add "linus.patch" as the first entry in your ./series file and
  start pushing your other patches on top of that.


Tons and tons.  The scripts are fragile, the error handling is ungraceful and
if you do something silly you can end up in a pickle.

Generally the scripts are very careful to not wreck your files or your
patches.  But they can get the ./applied-patches and ~-files into an
awkward state.

Usually you can sort it out by copying the ~-files back onto the originals
and removing the last line from ./applied-patches.  Or do a "refpatch ;
poppatch ; rm patches/troublesome-patch.patch ; cvs up patches".

If it's really bad, just blow away the entire tree and do a new CVS checkout.

Working on non-kernel projects

Well it's the same thing.  Say you've downloaded a copy of util-linux
and you want to make a change:

        cd /usr/src
        tar xvfz ~/util-linux.tar.gz
        cd util-linux
        mkdir pc patches txt
        fpatch my-patch sys-utils/rdev.c
        fpatch sys-utils/ipcs.8
        <edit, edit>
        <ship patches/my-patch.patch>

How to balls things up

Well here's one way.  Suppose you have 20 patches applied, and three of
them (say, "p1", "p6" and "p11") all modify "foo.c".

Now you go and change foo.c.

Well, to which patch does that change belong?  You need to decide.
Let's say you decide "p6".

If you run `refpatch' when "p11" is toppatch then you lose.  The diff
went into p11.

What you can do is:

        poppatch p6
        pushpatch p11

  (See why ccache is looking good?)


        poppatch p6     <hope like hell that the other patches remove cleanly>

Another good way of ballsing up is to cheat.  Say "oh I just want to make
this one-line change".  And "oh, and this one".

Now you're getting in a mess.  It's much, much better to just use the system:

        fpatch junk file1
        fpatch file2
        rm pc/junk.pc patches/junk.patch

Merging with -mm kernels

Haven't tried this, but it should work:

- Grab all the patches from broken-out/, place them in your ./patches/

- Copy my series file into ./series (or ./pc/akpm-series and symlink it)

- pushpatch 99

And you're off and running.  The nice thing about this is that you can
send me incremental diffs to diffs which I already have.

Or whatever.  I'm fairly handy with diffs nowadays.  Rejects are
expected.  I just prefer to have "one concept per diff".

Oliver Xymoron was very impressed with all of this, and said, "My own personal scripts (while obviously not getting nearly the workout yours are) make at least one part noticeably simpler - I use a complete 'cp -al' for the current "top of the applied stack" rather than your foo.c~bar files. This means I don't have to explicitly keep track of which files I'm touching and just let diff compare the entire tree (which is fast as diff apparently recognizes hard links). My equivalent of refpatch spews out a diffstat so that I can easily notice if I touched something I didn't mean to." Andrew replied:

That has always seemed unnatural to me. By keeping everything in the one tree you can easily:

Dunno. There are probably ways of doing all these things with a whole-tree copy, but I haven't tried to plot it all out.

Changelog tracking is fairly important to me also.

mnm:/usr/src/25> ls -l txt|wc -l

20. Linux Kernel conf 1.1

20 Oct 2002 (1 post) Archive Link: "linux kernel conf 1.1"

People: Roman Zippel

Roman Zippel announced:

At you can find the latest version of the new config system. Smaller changes:

The only big change this time is that I added a SWIG interface, which allows to generate a extension library for your favourite script language. I did this already for ruby, 'make ruby' builds the library in the .ruby subdir. I also included some examples.

21. Preparing For Final Merge Before 2.5 Feature Freeze

20 Oct 2002 - 21 Oct 2002 (11 posts) Archive Link: "Crunch time -- Final merge candidates for 3.0 (the list)."

Topics: Access Control Lists, Device Mapper, Disk Arrays: EVMS, Disk Arrays: LVM, Executable File Format, Extended Attributes, FS: NFS, FS: ext2, FS: ext3, Feature Freeze, Kexec, Version Control, Virtual Memory

People: Rob LandleyDenis VlasenkoKarim YaghmourAndrew MortonGeorge AnzingerHans ReiserDaniel PhillipsLinus TorvaldsAndreas DilgerHirokazu TakahashiAlan CoxJames SimmonsTheodore Y. Ts'oRoman ZippelEric W. BiedermanDave McCrackenGuillaume Boissiere

Rob Landley reported:

Okay, Linus has left for the Linux Lunacy Cruise (see ( ), which ends october 27. When he gets back, he's implied that there will be EXACTLY ONE more set of last minute merges before we switch over to the 3.0-pre (or 2.6-pre) series. Those of you waiting for the last minute: this is it.

There are people patch-hoovering while Linus is off "lecturing" on a boat in the carribean, but we don't know who those are, so that's not useful. What IS useful is knowing what the candidate patches are. Not bug fixes, but new features with one final shot at 2.5.45.

He posted a list of merge candidates culled from Guillaume Boissiere status list ( :

To the above can be added the following recent submission on the list:

He went on:

That's currently it, that I'm aware of. If your patch isn't on that list, and getting testing by people on linux-kernel (and getting a bunch of satisifed users to go "worked for me!" at it), then you should speak up and GET it on that list, or wait for the next development series.

When Linus comes back, at best he's going to give a thumbs up or thumbs down to each patch currently sitting there in front of him, and then it's on to the feature freeze. He may not take any of them, or he may just take one or two. But the best we can hope to do is present him with a nice (short) list of tested patches. (Remember, the less work Linus has to do, the higher the percentage of it that will actually get done.)

So everybody, try the above patches. If they work for you, say so on this list. It's no guarantee, but Linus has said endorsements from testers can make him feel more comfortable about a patch. Possibly we can collect a list of names of people for whom a patch "worked for me", to add to the list.

If your patch isn't on the list, speak out now. Better yet, post a URL to the latest version. It's "show me the code" time. (Yes, Hans Reiser, this means you. :) There are still 7 days till the end of Linus's cruise, but that's not much time to get guinea pigs to publicly pipe up with a hearty "AOL!" of support for your work...

Again, some of the things on this list won't make it into 3.0. It's just candidates. But everything that is NOT on this list in about 7 days is probably going to become 3.1 material by default.

Speak now, or till 3.1 hold your peace...

Hans Reiser said his group would send Reiser4 out by around the 27th.

Denis Vlasenko suggested, "Well, maybe it makes sense to reduce flow of non-features patches for a couple of days to let Linus feel less buried in email? I think VM tweaking and such... It could be done after Linus say what got in and what did not." Rob replied:

It would also be nice to buy the dude his own private jet, but I'm not sure it's a practical suggestion in the short term. :)

Linus has already said he intends to read his mail with the "D" key when he gets back. The point of collating the pending feature list is to pluck stuff out of the mess, shake it off a bit, and present him with a nice menu to make choices from on his return.

Deciding not to include stuff is Linus's perogative. (More than that, it's more or less his JOB in kerneldom, acting as goalie for the main tree.) Once again, we're just trying to make sure nothing gets dropped because he didn't see it rather than because he saw it and went "no".

In the past half-hour, the MMU-less patch and unlimited groups support have been fielded as "ready for 2.5", although I haven't seen URLs to either yet. Add Rusty's three items and we're up to... 19? Plus Hans Reiser said reiser4 will be ready around the 27th, so that's 20.

I don't think half that many will make it into 2.5, but some of them are small, so...

Regarding the status of LTT, Karim Yaghmour said:

LTT has seen a number of changes since the posting above. Mainly, we've followed the recommendations of quite a few folks from the LKML. Here are some highlights summarizing the changes:

The latest patch is available here:
Use this patch with version 0.9.6pre2 of the user tools:

Rob said:

Another thing I've noticed somebody still hoping to shoehorn into 2.5 is Roman Zippel's new kernel configuration system, which is here:


That was listed as a "beta" on the status list, I guess at version 1.1, it has now been promoted. (Anything else on the beta that's still trying to make it into 2.5? The 27th is sunday, meaning Linus should be back at transmeta on monday. Assuming 2.4.45 ships on the 31st, that would be the following thursday...)

Ted Tso has also been posting new ext2/ext3 code with extended attributes and access control lists.

Code (chooe your poison):

Apparently generic ACL support went into 2.5.3 (the status list again), but I guess it wasn't added to EXT2. I suppose this makes this a good candidate for inclusion then. :)

So, 11 items from the 2.5 status list (in -aa, in -mm, and "ready"), plus kexec, kernelconfig, and ACL for EXT3. I believe this brings the total number of pending patchsets still hoping for 2.5 inclusion to 14.

I can repost the full list if nobody beats me to it, but I think I'll wait to see who else pipes up first. :)

Andreas Dilger said he thought Theodore Y. Ts'o's EA/ACL work had made it into Andrew Morton's -mm kernel series. Rob asked if this meant it would definitely make it into Linus Torvalds' tree. Andreas said no, it was no guarantee, but it was a step in the right direction. Andrew also confirmed that his tree was not a magic carpet into the kernel, saying:

It's mainly there for the other VM/MM/IO developers to integrate against.

Also for getting their more experimental work more testing and exposure.

Also for getting external testing of the performance work which is going into it.

Also for maintainers of other architectures to pick up breakage before things break.

I prefer to only send things which I understand and have tested. So that excludes, say, dcache-rcu and the EA/xattr patches. I did send ext3-htree, but it had big "I haven't tested this" labels all over it.

22. Kernel 2.5.44-mm2 Released

21 Oct 2002 (6 posts) Archive Link: "2.5.44-mm2"

Topics: Access Control Lists, SMP

People: Andrew Morton

Andrew Morton announced:


23. RSBAC 1.2.1 Released

22 Oct 2002 (1 post) Archive Link: "Announce: RSBAC v1.2.1 released"

Topics: Access Control Lists, BSD: FreeBSD

People: Amon Ott

Amon Ott announced:

Rule Set Based Access Control (RSBAC) version 1.2.1 has been released. Full information and downloads are available from

RSBAC is a flexible, powerful and fast open source access control framework for current Linux kernels, which has been in stable production use since January 2000 (version 1.0.9a). All development is independent of governments and big companies, and no existing access control code has been reused.

This version comes with many smaller improvements against 1.2.0 and some new features, e.g.:







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 All pages on this site are copyright their original authors, and distributed under the terms of the GNU General Public License version 2.0.