Kernel Traffic
Home | News | RSS Feeds | Mailing Lists | Authors Info | Mirrors | Stalled Traffic

Kernel Traffic #189 For 20�Oct�2002

By Zack Brown

Table Of Contents

Mailing List Stats For This Week

We looked at 2948 posts in 16173K.

There were 629 different contributors. 343 posted more than once. 260 posted last week too.

The top posters of the week were:

1. Next Stable Series: 2.6 Or 3.0?

23�Sep�2002�-�14�Oct�2002 (209 posts) Archive Link: "[TCH-RFC] 4 of 4 - New problem logging macros, SCSI RAID device driver"

Topics: Disks: IDE, Forward Port, Networking, SMP, Virtual Memory

People: Jeff Garzik,�Linus Torvalds,�Ingo Molnar,�J.W. Schultz,�Denis Vlasenko,�Andi Kleen,�John Bradford,�Andre Hedrick

In the course of discussion, Jeff Garzik asked Linus Torvalds, "is it definitely to be named 2.6? Maybe it's just my impression from development speed, but it felt more like a 3.0 to me :)" Linus replied:

I see no real reason to call it 3.0.

The order-of-magnitude threading improvements might just come closest to being a "new thing", but yeah, I still consider it 2.6.x. We don't have new architectures or other really fundamental stuff. In many ways the jump from 2.2 -> 2.4 was bigger than the 2.4 -> 2.6 thing will be, I suspect.

But hey, it's just a number. I don't feel that strongly either way. I think version number inflation (can anybody say "distribution makers"?) is a bit silly, and the way the kernel numbering works there is no reason to bump the major number for regular releases.

Ingo Molnar argued:

i consider the VM and IO improvements one of the most important things that happened in the past 5 years - and it's definitely something that users will notice. Finally we have a top-notch VM and IO subsystem (in addition to the already world-class networking subsystem) giving significant improvements both on the desktop and the server - the jump from 2.4 to 2.5 is much larger than from eg. 2.0 to 2.4.

I think due to these improvements if we dont call the next kernel 3.0 then probably no Linux kernel in the future will deserve a major number. In 2-4 years we'll only jump to 3.0 because there's no better number available after 2.8. That i consider to be ... boring :) [while kernel releases are supposed to be a bit boring, i dont think they should be _that_ boring.]

J.W. Schultz made the point that -- as far as he could recall -- the jump from 1.0 to 2.0 was made because of changes in the Application Binary Interface (ABI). He said, "I have no problem with a version 2.42 if things stay stable that long. I hope they don't but that is another issue." [...] "It may be that 2.7 will see the cruft cut out and be the end of 2.x but 2.5 isn't that. So far 2.5 is performance enhancement. Terrific performance enhancement, thanks to you and many others. But it isn't adding major new features nor is it removing old interfaces. In many ways 2.6 looks like a sign that the 2.x kernel is getting mature. 2.6 means users can expect improvements but don't have to make big changes. 2.6 is an upgrade, 3.0 would be a replacement." Denis Vlasenko agreed, saying, "Technically correct. Major version jump should be made when there is a binary incompatibility. It can be made without, but it is usually done for marketing reasons. I hope we'll never have marketing reasons for lk. :-) We can be actually _proud_ to have 2.$BIGNUM instead of 3.0"

Elsewhere, Linus said to Ingo:

Hey, _if_ people actually are universally happy with the VM in the current 2.5.x tree, I'll happily call the dang thing 5.0 or whatever (just kidding, but yeah, that would be a good enough reason to bump the major number).

However, I'll believe that when I see it. Usually people don't complain during a development kernel, because they think they shouldn't, and then when it becomes stable (ie when the version number changes) they are surprised that the behabviour didn't magically improve, and _then_ we get tons of complaints about how bad the VM is under their load.

Am I hapyy with current 2.5.x? Sure. Are others? Apparently. But does that mean that we have a top-notch VM and we should bump the major number? I wish.

The block IO cleanups are important, and that was the major thing _I_ personally wanted from the 2.5.x tree when it was opened. I agree with you there. But I don't think they are major-number-material.

Anyway, people who are having VM trouble with the current 2.5.x series, please _complain_, and tell what your workload is. Don't sit silent and make us think we're good to go.. And if Ingo is right, I'll do the 3.0.x thing.

A lot of people started talking about how they were unable even to test 2.5, because of the IDE instability or the fact that the kernel wouldn't compile. This, they said, made it difficult to answer Linus' requests. Andre Hedrick (IDE maintainer) mentioned at one point that he was still hesitant to make large changes, as he hadn't finished studying the forward-port of the 2.4 IDE code. A number of developers in this part of the discussion, including Linus, said that 2.5 worked fine for them, but this didn't seem enough to entice the skeptics.

Elsewhere, John Bradford also suggested that a stable IPv6 should be a requirement for a major version jump to 3.0; and Andi Kleen replied:

Actually current IPv6 is stable and has been for a long time, it's just not completely standards compliant (but still quite usable for a lot of people)

If you mean stable implies the latest whizbang features you have a different meaning of stable than me.

Elsewhere, John remarked that, in terms of when to jump to 3.0, Linus should "stick to" the policy of doing so to reflect ABI incompatibilities. Linus replied:

"Stick to"? We've never had that as any criteria for major numbers in the kernel. Binary compatibility has _never_ been broken as a release policy, only as a "that code is old, and we've given people 5 years to migrate to the new system calls, the old ones are TOAST".

The only policy for major numbers has always been "major capability changes". 1.0 was "networking is stable and generally usable" (by the standards of that time), while 2.0 was "SMP and true multi-architecture support". My planned point for 3.0 was NuMA support, but while we actually have some of that, the hardware just isn't relevant enough to matter.

The memory management issues would qualify for 3.0, but my argument there is really that I doubt everybody really is happy yet. Which was why I asked for people to test it and complain about VM behaviour - and we've had some ccomplaints ("too swap-happy") although they haven't sounded like really horrible problems.

2. BitKeeper Licensing Discussion

4�Oct�2002�-�11�Oct�2002 (271 posts) Archive Link: "New BK License Problem?"

Topics: Version Control

People: Tom Gall,�Larry McVoy,�Ben Collins,�Ingo Molnar,�Rob Landley,�Ulrich Drepper,�Rik van Riel,�Nicolas Pitre,�Hans Reiser

Filesystems Real-Time

This discussion has been going on since early October, and I've gotten several alarmed emails from folks asking why I hadn't covered it in KT. The reason is, the discussion has been ongoing all this time. It seems to have stopped, for now. Here are some highlights.

Tom Gall reported:

I noticed Larry recently changed the license on bk. Once clause in particular struck me and I thought I'd better point it out for your reactions...

Specifically from Section 3:

(d) Notwithstanding any other terms in this License, this License is not available to You if You and/or your employer develop, produce, sell, and/or resell a product which contains substantially similar capabil- ities of the BitKeeper Software, or, in the reason- able opinion of BitMover, competes with the BitKeeper Software.

Doesn't this affect maintainers all across the map that work for distros such as RedHat, SuSE, Connectiva, etc? Obviously these distros SELL as part of their respective products CVS and similar tools. Or even non-distro open source shops, you even resell CVS or the like in some way and you'd be in trouble.

Hans Reiser felt this was a clear violation of anti-trust laws in the U.S. Murray J. Root agreed with this, but Larry McVoy of BitMover replied that, as the licence only covered the free use of BitKeeper, in which no money changed hands, "I'm pretty sure that the courts will let us decide under what terms we allow people to use our software for free." He also invited Murray to sue BitMover.

Elsewhere, Larry pointed out to Tom, that distributions like Red Hat and the others did not sell CVS and other BitKeeper competitors, they distributed them. He said, "We choose those words with care for exactly that reason." Tom replied, "Of course they sell CVS. I give them money, they give me a CD, that CD has CVS on it. If I have a support contract with that distro and CVS breaks they will fix it." Larry replied, "That's your opinion. That's not our opinion."

Elsewhere, Ben Collins asked:

Larry, I develop for the Subversion project. Does that mean my license to use bitkeeper is revoked?

I've also been wanting to use bitkeeper to create a Subversion mirror of the kernel repository, but I suspect that my usage falls seriously into this category, as my reasons for doing so are three-fold; allow access to the bkbits repo to folks who don't want to use bk, but with all the joys of an SCM (history, changesets, etc.); stress test Subversion against a real-world high-activity repo; promote Subversion.

Would it be your intention that your license disallow my type of work? I think it does.

Larry replied, "You bet it does. The Subversion folks would like nothing better than to displace BK. That's fine, but they don't get to use BK to do it. You're absolutely correct that you could use BK to make Subversion better. It is not our job to help you make Subversion better and we've made that clear for a long time." Ben replied, "Fact is, I've heard many Subversion core developers say, and I quote, "If BK were open-sourced, we'd just pack up and go home". Fact is, Subversion is not geared to replace BK, nor has the Subversion team ever claimed it as such. Fact is, the website clearly states it is a CVS replacement, which is not on par with what BK does else BK would never have come into existence." He added, "You've clearly made your point. I'll delete my copy of BK since I have no legal license to use it. That's all I wanted to know."

Elsewhere, Ingo Molnar connected two of Larry's statements, which he felt contradicted each other. Larry had said, "The clause is specifically designed to target those companies which produce or sell commercial SCM systems. [...] The open source developers have nothing to worry about." A day later, in response to Ben's question about whether his free license had been revuked, Larry had said, "Yes. It has been since we shipped that license or when you started working on Subversion, whichever came last." Ingo concluded from this:

this kind of sudden change in Larry's written opinion within 24 hours is what makes this whole issue dangerous. Fact is that Larry is free to license his product under fair or unfair terms - it's his. While we already gave BK/BM tons of feedback, free beta-testing and free publicity, all we have is this volatile promise that the binary bits of BK are going to remain licensed - and with every day it will be harder and harder to move the repository.

what happens if Linux merges some sort of kernel based versioned filesystem, eg. something similar to what ClearCase does today? Will the license suddenly change to 'as long as you do not work on the versioned-FS kernel subsystem'? Or isnt this already a violation of the current license?

this is why i'd rather want to have an iron-clad legal way out first, and not have to rely on nonbinding promises done on public lists. I'm sure Larry understands this position, he has exactly the same position when trying to protect his business against hordes of freebies.

He replied to himself:

Larry, a simple question: does the BK license allow the Rational kernel developers to use BK (to eg. check out Linus' tree) when working on kernel support for ClearCase?

ie. is all kernel development activity against your license as long as the activity is a competitor of yours?

Larry avoided the question, saying the license answered it already. Ingo asked again, "so BK cannot be used to access the kernel tree in that case, correct? I'm just wondering where the boundary line is. Eg. if i started working on a versioned filesystem today, i'd not be allowed to use BK. I just have to keep stuff like that in mind when using BK." Larry again avoided the question. Rob Landley pointed out that Larry was avoiding the question, and tried a third time to get an answer. Larry replied, "What is with you anyway? Do you have nothing better to do than try and yank my chain and cause trouble?" Rob said, "Actually, I was just hoping to prod you into answering Ingo's question..." Larry did not reply.

Elsewhere, Ben asserted that he personally hadn't been using BitKeeper for kernel development, and so losing his BitKeeper license would not directly impact his ability to contribute to the kernel. But he pointed out:

Now, other more serious kernel developers who have been using BK for some time, may one day find they'd like to help a competing project. They have to make a choice between the means that they develop for the linux kernel and helping a project they have become interested in.

Suddenly all the kernel developers who have staked their work in BK cannot work on a "competing" product to BK, without changing their development model.

Ulrich Drepper picked up that point and ran with it:

Not only this, it gets worse.

In my case it is almost impossible to not get involved in many many free software projects. gettext or i18n in general, of glibc related issues pop up everywhere and often I contribute patches. Subversion is one of the projects where this has been the case in the past.

According to my understanding this means I'm tainted (I've asked Larry for confirmation).

Now the important part: I still have to work closely with kernel developers. The npt work is one example: I had to check out Ingo latest patches in the kernel every day. Now this isn't possible anymore without

  1. me finding another route to get the latest kernel in realtime (which still could be considered illegal since somebody else, for the expressed purpose of making the result available to me, is using bk);
  2. the kernel developers I work with not depending on bk anymore.

The second point is what is causing the trouble. Any team which wants to use bk to synchronize the work is tainted by one single individual being tainted.

I have never looked closer at bk than I had to be able to check out the latest sources. I'm not doing any development with it and I'm not checking in anything using bk.

Nicolas Pitre suggested that Larry produce a special version of BitKeeper that could only do checkouts, and Larry replied, "You can do this today. rsync a BK tree and use GNU CSSC to check out the sources." Rik van Riel said at one point:

People can grab the repository for use with CSSC from:

Or using rsync:
rsync -rav --delete linux-2.4
rsync -rav --delete linux-2.5

Currently these repositories are updated every two hours, but if there is a large demand I could update it every hour or even every 30 minutes. Don't feel ashamed to put the above rsyncs into your crontabs, grab the source and use it ;)

3. Mount Rainier Support In 2.5

6�Oct�2002�-�11�Oct�2002 (4 posts) Archive Link: "Support for Mount Rainier / Packet Writing"

Topics: Feature Freeze

People: Jure Repinc,�Jens Axboe,�Andre Hedrick

Jure Repinc asked:

Now that feature freeze is just around the corner I would like to ask you if we will get support for packet writing in the 2.6/3.0 kernel. It would be especialy nice to have support for Mount Rainier which enables easy use of CD-RWs and that would help people (especially newbies) that use CD-RWs a lot.

There are some patches from Jens Axboe that are available here:

Are patches these OK for this or would support have to be completely rewriten?

Jens Axboe replied, "I had patches for 2.4 that enable mt rainier support in ide-cd and sr, they need to be polished a bit and submitted. I don't view the feature freeze as a big problem here, it's just minor additions to the cd-rom driver so..." Jure was very happy to hear this, and urged that the work be done. Andre Hedrick also repleid to Jure's original question, saying:

Well I have pressed the various legal departments in Mt-Rainer, and as long as we do not attempt to do non-native operations we should be clear.

Specifically legal, no license required :

MRW device and MRW media read/write is cool
MRW device format and create GAA, to create MRW from CDRW.

Specifically illegal, without a license agreement :

CDRW reading MRW media.
Building applications to stuff into the GAA to perform above.

These are key points, and the working group core has been blind cc'd.

4. procps Maintainership Conflict

8�Oct�2002�-�12�Oct�2002 (16 posts) Archive Link: "[ANNOUNCE] procps 2.0.10"

Topics: Maintainership, SMP

People: Rik van Riel,�Brandon Low,�Alexander Viro,�Albert D. Cahalan,�Marc-Christian Petersen,�Anton Blanchard,�Albert Cahalan,�Robert Love,�Denis Vlasenko

Rik van Riel announced procps 2.0.10 and said:

Procps is the package containing various system monitoring tools, like ps, top, vmstat, free, kill, sysctl, uptime and more. After a long period of inactivity procps maintenance is active again and suggestions, bugreports and patches are always welcome on the procps list.

The plan is to release a procps 2.1.0 around the time the 2.6.0 kernel comes out, with regular releases until then. Code cleanups and all kinds of enhancements are welcome.

You can download procps 2.0.10 from:

If you have feedback (or patches) for the procps team, feel free to mail us at:

NEWS for version 2.0.10 of procps

Brandon Low reported in alarm, "Hey, I just saw the recent announcement of procps-3.0.1 on the mailing list by the team, what is the status of these two projects, there are features in each that are very nice, the versioning is confusing, and inconsistant, and the package names are the same..." Alexander Viro replied:

Simple: Albert's one is, well, Albert's. If it gets into sarge, procps gets on hold on my boxen, so I'm not too concerned...

I would (read: will) go with Rik's variant - unlike Albert he got taste. YMMV.

And Rik also said:

Albert Cahalan's procps seems to be focussed on rewriting and improving procps.

The procps project I'm maintaining is more focussed on supporting the latest stats exported by 2.5. I hope to get some time to clean up the source code, too...

In a completely different thread, under the Subject: [ANNOUNCE] procps 3.0.1, Albert D. Cahalan announced his own version of procps, 3.0.1:

Contrary to popular belief, procps is maintained. Craig Small, Jim Warner, and I have kept it up to date for several years now. Now I see that keeping a low profile is really bad, so here goes...

Changes that you may be unaware of and/or need:

top: windows, color, sort any field, 2.5.xx kernel support
sysctl: supports the VLAN interfaces
ps: runs 2x faster than procps-2.x.x did
vmstat: 2.5.xx kernel support

Get it here:

We use for feedback and for announcements.

Marc-Christian Petersen wrote privately to Albert, saying the kernel 2.5 support was broken. Albert replied cryptically, "You're running a 2.2.xx or 2.0.xx non-SMP kernel, aren't you? No problem anymore, get the 3.0.2 release." Marc-Christian replied, "err, I wrote 2.5.xx ?! ... I don't run 2.2.xx nor 2.0.xx kernels!" There was no reply.

5. Linux 2.4.20-pre10 Released

8�Oct�2002�-�11�Oct�2002 (5 posts) Archive Link: "Linux 2.4.20-pre10"

Topics: FS: NFS

People: Marcelo Tosatti

Marcelo Tosatti announced:

Here goes pre10.

This version fixes the NFS hang which was introduced in early 2.4.20-pre's plus some smaller fixes.

6. Linux Kernel conf 0.8 Released

8�Oct�2002�-�10�Oct�2002 (34 posts) Archive Link: "linux kernel conf 0.8"

Topics: Kernel Build System

People: Roman Zippel,�Linus Torvalds,�Brendan J Simon,�Randy Dunlap

Roman Zippel announced:

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

As already mentioned before lkc is pretty much ready (except for kbuild integration).

Linus, do you have any interest in merging it in the near future? If not, what's missing?

The 2.5.40 release showed again, how bad three different parsers are, so I think it's important to fix this finally for 2.6.

Changes this time:

Linus Torvalds replied privately to Roman:

I'm not super-excited about this, partly because of the brouhaha last time around on this issue.

This has reasonably distributed config files, and puts the help with the config entry where it belongs. Good. It also makes do with just standard unix tools, which is going to avoid one particular rat-hole, and which makes me at least understand the code. Also good.

Linus also said that the dependency of xconfig on the QT library would make certain people hate it. Roman replied, on-list, that QT just happened to be the library he knew; he had no objection to using a different one, but someone else would have to write it because he didn't know how. Brendan J Simon pointed out that this was likely to lead to religious wars akin to KDE vs. Gnome, adding, "I'm pretty sure there is no one solution and it comes down to the politics and preferences of the final decision makers up the heirarchy." Roman replied, "Because of this I'm planning to make the config backend available as shared library, so it can be loaded by external programs. My QT app then would be basically just the reference implementation." Close by, Randy Dunlap suggested just sticking with Tcl/Tk, which was the current xconfig implementation, but Linus replied:

Too ugly. I actually think QT is a fine choice, I just suspect that it's going to cause political issues.

My favourite approach by far is to actually not ship anything graphical with the kernel at all, and just hope that the config language syntax is stable enough that different groups can do their own as external packages.

The kernel would ship with just the text-based "reference implementation" (if even that - we could just have a few "supporting packages").

The only thing I personally really care about is the Config language, since that _has_ to ship with the kernel.

Randy replied, "So I think that you and Roman are close to agreement, when Roman has the library backend ready. Of course someone needs to do a "reference implementation" with it also, but it doesn't need to ship with the kernel."

In his original private reply to Roman, Linus also complained that he hadn't seen any discussion of Roman's work on linux-kernel, "because (apparently as usual), all the discussion is held in a small world of its own." Roman explained that there really hadn't been any discussion, because people were afraid of re-invoking the flame-wars that surrounded other configuration systems like CML2. He added, "what you've seen so far on lkml is pretty much almost all the feedback I got. It seems unless you state that you're not completely opposed to it, I'm afraid it won't get better."

7. IPMI Driver Version 5

9�Oct�2002�-�12�Oct�2002 (3 posts) Archive Link: "[PATCH] IPMI driver for Linux, version 5"

People: Corey Minyard

Corey Minyard announced, "I have put a new version of the IPMI driver on my home page ( that removes the Linus-incompatable typedefs. The only typedefs left are "handle" ones." He added, "In case you don't know, IPMI is a standard for system management, it provides ways to detect the managed devices in the system and sensors attached to them. You can get more information at"

8. Memory Binding For Better VM Control In 2.5

9�Oct�2002�-�15�Oct�2002 (29 posts) Subject: "[rfc][patch] Memory Binding API v0.3 2.5.41"

Topics: Feature Freeze, SMP, Virtual Memory

People: Matthew Dobson,�Martin J. Bligh,�Arjan van de Ven,�Andrew Morton

Matthew Dobson announced:

Here's a wonderful patch that I know you're all dying for... Memory Binding! It works just like CPU Affinity (binding) except that it binds a processes memory allocations (just buddy allocator for now) to specific memory blocks.

I've sent this out in the past, but haven't touched it in months.

Since the feature freeze is rapidly approaching, I want to get this out there again and see if anyone has any interest in it.

It's a fairly large patch, mostly because it includes a few odds and ends that are topology related, and don't strictly belong in this patch, but are pre-requisites for it (ie: the [memblk|node]_online_map stuff, and some of the cleanups to page_alloc). I'll probably try and break it up into more discrete parts very soon.

Andrew Morton and Martin J. Bligh liked the patch, and began asking about the implementation; but Arjan van de Ven thought CPU binding should be enough for any system with a working Virtual Memory subsystem. Matthew replied, "This patch is for processes who feel that the VM *isn't* doing quite what they want, and want different behavior."

9. Linux 2.5.41-mm2 Released

9�Oct�2002�-�10�Oct�2002 (5 posts) Archive Link: "2.5.41-mm2"

Topics: Networking

People: Andrew Morton,�Ingo Molnar,�Dave Hansen

Andrew Morton announced:


Ingo Molnar replied:

i sent my latest timer patch to Dave Hansen but have not heard back since. I've attached the latest patch, this kernel also printks a bit more when it sees invalid timer usage.

in any case, the oops Dave was seeing i believe was fixed by Linus (the PgUp fix), and it was in the keyboard code. If there's anything else still going on then the attached patch should either fix it or provide further clues.

And Dave Hansen said, "Sorry, I haven't had a chance to test it yet. The Specweb setup likes to eat ethernet cards and I haven't put in replacements yet. I'll try and get some time in on it tomorrow."

10. Maintainer List

10�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 Vlasenko,�Ingo Oeser,�Trond Myklebust,�Jan Kara,�Arnaldo Carvalho de Melo,�Alexander Viro,�Hans Reiser,�Rik van Riel,�Linus Torvalds,�Vojtech Pavlik,�Geert Uytterhoeven,�Andre Hedrick,�Jeff Garzik,�Greg KH,�Jaroslav Kysela,�Anton Altaparmakov,�Tigran Aivazian,�Martin J. Bligh,�Arjan van de Ven,�Eric S. Raymond,�Mike Phillips,�Oleg Drokin,�H. Peter Anvin,�Alan Cox,�Pavel Machek,�Dave Jones,�Richard Gooch,�Andrew Morton,�Jens Axboe,�James Simmons,�Ingo Molnar,�Victor Yodaiken,�Tim Waugh,�Rusty Russell,�Gerd Knorr,�Andrea Arcangeli,�Martin Dalecki,�David S. Miller,�Jan-Benedict Glaw,�Rogier Wolff,�Urban Widmark,�Paul Larson,�Petr Vandrovec,�Marcelo Tosatti,�Neil Brown,�Russell King,�Ralf Baechle,�Robert Love,�Maksim Krasnyanskiy,�Stuart MacDonald

Denis Vlasenko posted his current list of 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

Regarding Eric S. Raymond's entry, Ingo Oeser asked, "Isn't this Steven P. Cole <> now? Or is Eric still responsive to patches?" There was no reply.

11. Fix To Allow IDE To Build As A Module

10�Oct�2002 (3 posts) Archive Link: "Patch: linux-2.5.41/drivers/ide - build IDE as a module"

Topics: Disks: IDE

People: Adam J. Richter,�Alan Cox

Adam J. Richter said:

The following patch seems to fix building IDE as a module in 2.5.41. I am running this code on the machine that I'm using to compose this email.

A couple of notes:

  1. For the time being, I have reassembled some of the drivers/ide object files into ide-mod.o again, because there are some circular references (not necessarily a bad thing) that modprobe cannot otherwise handle. For now, this includes putting ide-probe in ide-mod.
  2. I have changed cmd640.o and legacy.o from dep_bool to dep_tristate and made them also depend on $CONFIG_BLK_DEV_IDE, so that they will only be offered as modules if ide-mod.o is a module (since, like any IDE driver, they require some symbols in ide-mod.o).

These changes are probably not perfect, but I think they should be an improvement with no real disadvantages in comparison to what they replace, so I would encourage you to integrate the changes if you see no problem. Please let me know what you want to do, or if there is something more you'd like me to do regarding this patch.

Alan Cox had a few comments, and added, "I have no major problem with applying them and working from there to clean up the corners. Firstly however do one little thing - dont put extern blah() in the code, add them to the right header files." Adam agreed to this and posted an updated patch.

12. EVMS Update

10�Oct�2002 (15 posts) Archive Link: "[PATCH] EVMS core (0/9)"

Topics: Disk Arrays: EVMS, Ioctls

People: Kevin Corry

Kevin Corry posted a bunch of patches and said:

On behalf of the EVMS team, I would like to submit the Enterprise Volume Management System for review and possible inclusion in the 2.5 kernel.

This submission includes only the core driver and include files. Additional plugins will be submitted in the future in separate patches.

This series of patches contains the following files:

  1. evms.c
  2. services.c
  3. discover.c
  4. passthru.c
  5. evms_core.h
  6. evms.h
  7. evms_ioctl.h
  8. evms_biosplit.h
  9. miscellaneous files

If you are interested in other information about EVMS, or would like to obtain the user-space administration tools, please visit our website at

Thank you very much for taking the time to review this submission. If you have any questions or comments, please email us at any time. We will be happy to do whatever is necessary to make EVMS acceptable for inclusion in the 2.5 tree.

13. CIFS Filesystem For 2.5

10�Oct�2002 (4 posts) Subject: "[BK PATCH] CIFS filesystem for Linux 2.5"

Topics: FS: CIFS, Samba, Version Control

People: Steven French,�Jeremy Allison

Steven French announced, "The CIFS filesystem has been updated to handle yesterday's changes to the superblock structure and has been added to a new bitkeeper repository as a single bitkeeper changset in order to be easier to apply. It is changeset number 1.747 at bk:// and is low risk, not changing core kernel files." Jeremy Allison replied, "I'd love this to be included into 2.5.x Linux, as it is a very nicely written, modern CIFS client that we can use to start adding UNIX specific extensions into Samba, and hopefully end up with a filesystem that uses UNIX semantics when talking to a Samba server, and will fall back to Windows semantics when talking to lagacy Windows server (I really love saying that :-) :-). Should be a big help in making Linux the "universal client glue" we know and love .... :-)."

14. Shared IDE Maintainership

10�Oct�2002�-�11�Oct�2002 (2 posts) Subject: "Task Share Maintainership"

Topics: Disks: IDE, Maintainership

People: Andre Hedrick,�Bartlomiej Zolnierkiewicz

Andre Hedrick said:

It is time for you to step up to the plate!

As many people know, Bartlomiej is someone whom I trust with the driver without reservations. Since I am off working on several other issues, I would request the Maintainership be dual duty split over all kernel versions regardless. I am hoping Bartlomiej will accept the shared task and everyone will accept his input without question, this includes me too.

I will still be around and active; however, the task is so large now it truly does require a team. Please sign up to help Bart.

Bartlomiej Zolnierkiewicz replied, "Accepted, thanks!"

15. Advanced TCA Hotswap Support

10�Oct�2002�-�15�Oct�2002 (18 posts) Subject: "[PATCH] [RFC] Advanced TCA Disk Hotswap support in Linux Kernel [qla2300 2/2]"

Topics: Disks: SCSI, FS: devfs, Ioctls, Networking

People: Steven Dake,�Randy Dunlap,�Corey Minyard

Steven Dake posted a patch and announced:

I am developing the Linux kernel support required to support Advanced TCA (PICMG 3.0) architecture. Advanced TCA is a technology where boards exist in a chassis and can either be processor nodes or storage nodes. All blades in the chassis are connected by FibreChannel and Ethernet. The blades can be hot added or hot removed while the Linux processor nodes are active, meaning that the SCSI subsystem must add devices on insertion requests and remove devices on ejection requests.

The following is the first public patch that I am posting that adds support for SCSI and FibreChannel hotswap via a programmatic kernel interface, as well as userland access via ioctls.

The second patch is a FibreChannel driver that is modified to support SCSI hotswap.

This mechanism is far superior to /proc/scsi/scsi because it:

  1. provides true FibreChannel hotswap support (at this point qlogic FC HBAs)
  2. is programmatic such that errors can be reported from kernel to user without looking is /var/log/.
  3. Provides superior response times vs opening a file and writing to proc.
  4. Easier to control from kernel and user via C APIs vs using open/write.

Randy Dunlap asked for a URL, and Steven said he'd post a Sourceforge link later that day. Later on, under the Subject: [ANNOUNCE] [PATCHES] Advanced TCA Hotswap Support in Linux Kernel, he said:

I am announcing a sourceforge project for developing support in Linux kernel for Advanced TCA (PICMG 3.0) architecture. Advanced TCA is a technology where boards exist in a chassis and can either be processor nodes or storage nodes. All boards in the chassis are connected by FibreChannel and Ethernet. The blades can be hot added or hot removed while the Linux processor nodes are active, meaning, that the SCSI subsystem must add devices on insertion request and remove devices on ejection requests. Further the typical /dev/sda naming of devices is not appropriate since device nodes can change depending on the insertion order of disks.

These patches are for Linux 2.4.19 and work with the Qlogic 2300 FibreChannel driver and at this point mostly support hotswap of the disk subsystem.

The patches consist of a SCSI hotswap patch for 2.4 kernel and QLA 2300 support.

The patches also consist of a GA Mapper library which maps fibrechannel WWNs to devices in devfs filesystems such as /dev/scsi/chassis/slot/disc.

The sourceforge project also contains a userland library for each patch and userland applications such that these operations can be scripted.

Advanced TCA uses IPMI, so this project will use the IPMI driver being developed by Corey Minyard.

To be posted are userland or kernel hotswap managers. I've not decided how to do this yet, so I'll post the bits when they are done.

16. Linux Kernel conf 0.9 Released

14�Oct�2002�-�15�Oct�2002 (7 posts) Archive Link: "linux kernel conf 0.9"

Topics: Kernel Build System

People: Roman Zippel,�Sam Ravnborg

Roman Zippel announced:

At you can find as usual the latest version of the new config system. I still haven't got a single mail from someone who tried it and didn't like it, what makes me a bit nervous :), so if you think something must be wrong, now is your last chance. Next version will go to Linus. Changes:

17. User-Mode Linux Updated To 2.5.42 And 2.4.19-12

14�Oct�2002�-�15�Oct�2002 (9 posts) Archive Link: "uml-patch-2.5.42-1"

Topics: Kernel Build System, SMP, User-Mode Linux

People: Jeff Dike

Jeff Dike announced:

UML has been updated to 2.5.42 and UML 2.4.19-12. In non-numeric terms, this means the following:

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. Extended Attributes In ext2 And ext3

14�Oct�2002�-�15�Oct�2002 (18 posts) Subject: "[PATCH 1/4] Add extended attributes to ext2/3"

Topics: Access Control Lists, Extended Attributes, FS: ext2, FS: ext3, POSIX, Virtual Memory

People: Theodore Y. Ts'o,�Christoph Hellwig,�Andreas Gruenbacher,�Linus Torvalds,�Andrew Morton

Theodore Y. Ts'o announced:

Enclosed please find patches to add extended attribute support to the ext2 and ext3 filesystems. It is a port of Andreas Gruenbacher's patches, which have been quite well tested at this point. Full support for extended attributes have been in e2fsprogs for quite some time. In addition, if CONFIG_EXT[23]_FS_ATTR is not enabled, the code path changes are quite minimal, and hence this should be a very low-risk patch. Please apply.

These patches are a prerequisite for the port of Andreas Gruenbacher's ACL patches, which will follow shortly.

This first patch creates a generic interface for registering caches with the VM subsystem so that they can react appropriately to memory pressure.

Andrew Morton pointed out that some of this API had already been included in Linus Torvalds' tree; Theodore was happy about that. But elsewhere, Christoph Hellwig said, "It doesn't look like you addressed any comments raised, i.e. my complaints or sct's superblock fields. I"ll start feeding some updates to akpm to address a few issues, but I don't really have time to care of all that." Theodore replied:

Actually, I did, for those comments that made sense. The fs/ logic has been cleaned up, as well as removing excess header files, stray LINUX_VERSION_CODE #ifdef's that I had missed the first time around, etc.

fs/mbcache.c is still there because it applies to both ext2 and ext3 filesystems, and so your suggestion of moving it into the ext2 and ext3 directories would cause code duplication and maintenance headaches. It also *can* be used by other filesystems, as it is written in a generic way. The fs/ only compiles it in if necessary (i.e., if ext2/3 extended attribute is enabled) so it won't cause code bloat for other filesystems if it is not needed.

The superblock fields are more of an issue with the posix acl changes than for the extended attribute patches. I had wanted to get the extended attribute changes in first, since they stand alone, and so I have fewer patches to juggle.

Christoph proceeded to post several patches to address these various issues; and folks discussed their implementation.

19. Web Page For Trivial Patch Monkey

14�Oct�2002 (1 post) Archive Link: "[TRIVIAL] Trivial Web Page"

People: Rusty Russell

Rusty Russell announced:

Due to popular request[1], Trivial Patch Monkey acquires its own web page:


20. Support For Dial-Up Over PCNet Adaptors

15�Oct�2002 (4 posts) Archive Link: "AMD PCNet adapter"

Topics: Modems

People: Phil Brutsche

Anthony Martinez asked if there were any modem drivers available for AMD PCNet adapters using the AM79C978XC chip. Phil Brutsche replied:

Those aren't modem ports; those are POTS ports for HomePNA ( networking.

It will work fine using the RJ45 connector; chances are the PhoneNet networking will work fine if you just *try* it.

This didn't do it for Anthony. He needed dial-up connectivity, and went away frustrated.

21. Linux 2.5.42uc1 Released

15�Oct�2002�-�16�Oct�2002 (7 posts) Subject: "[PATCH]: linux-2.5.42uc1 (MMU-less support)"

Topics: Networking

People: Greg Ungerer

Greg Ungerer announced:

An updated uClinux patch is available at:


  1. v850 update
  2. cleaned up mm/page_alloc.c

Smaller specific patches:

22. Kernel 2.5 Exercised In LLC And Token Ring Features

15�Oct�2002 (4 posts) Archive Link: "LLC fix (was 2.5 token ring build fails)"

People: Kent Yoder,�David S. Miller,�Arnaldo Carvalho de Melo

Kent Yoder reported, "When building in TR support, LLC must also be included in the kernel, not as a module. LLC only builds correctly as a module however, due to llc_proc_exit (__exit code) being called from llc_init in llc_main.c. The following patch fixes this." He included his patch, and David S. Miller replied, "Already in our trees and pushed to Linus (who will hopefully pull them soon :-)" Arnaldo Carvalho de Melo added, "good to know that more and more people are trying 2.5 for stuff as uncommon as LLC and Token Ring 8) This is the third report I got, with a patch! :-)"

23. SMP Support For User-Mode Linux

15�Oct�2002 (1 post) Archive Link: "[PATCH] UML SMP support"

Topics: SMP, User-Mode Linux

People: Jeff Dike

Jeff Dike posted a patch and explained, "This adds SMP support to UML. All global data owned by UML is now either locked or is commented as to why no locking is needed. All interrupts are currently handled by CPU 0. The special handling of the timer interrupt is now gone."

24. Linux 2.4.20-pre11 Released

15�Oct�2002�-�16�Oct�2002 (4 posts) Archive Link: "Linux 2.4.20-pre11"

People: Marcelo Tosatti

Marcelo Tosatti announced 2.4.20-pre11, "with a lot of misc fixes. Users which had problems with pdcraid on 2.4.19, please try this one and report results."

25. POSIX Clock And Timer Functions

15�Oct�2002 (1 post) Subject: "[PATCH ] POSIX clocks & timers"

Topics: POSIX, Real-Time

People: George Anzinger

George Anzinger announced:

This, patch implements the POSIX clocks and timers functions. The two standard clocks are defined(CLOCK_REALTIME & CLOCK_MONOTONIC).

With this version, nano_sleep() is rolled into clock_nanosleep(). Also a bug fix in clock_nanosleep().

kernel/timer.c is modified to remove the timer_t typedef which conflicts with the POSIX standard definition for this type.

The patch introduces a new kernel source (posix-timers.c) which contains most of the code.

This implementation defines a timer as a system wide resource with system wide limits on the number of allocated timers. This number can be set at configure time and is defaulted to 3000. There are NO other limits on how many timers a process can have.

Kernel version 2.5.42-bk2

Test programs, man pages and readme files are available on the sourceforge high-res-timers site:

26. devfs v199.17 And v218 Available

15�Oct�2002 (2 posts) Subject: "[PATCH] devfs v199.17 available"

Topics: FS: devfs

People: Richard Gooch

Richard Gooch announced:

Hi, all. Version 199.17 of my devfs patch is now available from:
The devfs FAQ is also available here.

Patch directly available from:


This is against 2.4.20-pre11. Highlights of this release:

In a separate post, he also announced:

Hi, all. Version 218 of my devfs patch is now available from:
The devfs FAQ is also available here.

Patch directly available from:


NOTE: kernel 2.5.1 and later require devfsd-v1.3.19 or later.

This is against 2.5.43. Highlights of this release:

27. Linux 2.5.43-mm1 Released

15�Oct�2002�-�16�Oct�2002 (4 posts) Subject: "2.5.43-mm1"

Topics: Access Control Lists, Extended Attributes, FS: sysfs, POSIX, Virtual Memory

People: Andrew Morton

Andrew Morton announced:


28. User-Mode Linux Updated To 2.5.43

16�Oct�2002 (1 post) Subject: "[PATCH] UML updates"

Topics: User-Mode Linux

People: Jeff Dike

Jeff Dike announced:

This patch contains updates to 2.5.43 and syncs the 2.5 UML up with my 2.4 tree.

The 2.5.43 updates are build fixes, and updated defconfig, and an entry for lookup_dcookie.

The other stuff includes

not calling request_irq from an interrupt handler
fix a hang caused by xterm not running successfully
exporting rwlock symbols
killing off all the idle threads on halt
other small updates, fixes, and cleanups

29. KDB 2.3 Released For Kernel 2.5.43

16�Oct�2002 (1 post) Subject: "Announce: kdb v2.3 is available for kernel 2.5.43"

Topics: USB

People: Keith Owens

Keith Owens announced:


The usb keyboard patch has been merged from kdb v2.3-2.4.19-{common,i386}. It does not compile on 2.5.43, the APIs have changed. If you can help with usb polling support for kdb, grep for CONFIG_KDB_USB. Without community support, the usb support will be dropped.

Changelog extracts.


2002-10-17 Keith Owens <>

* Upgrade to 2.5.43.
* kdb v2.3-2.5.43-common-1.


2002-10-17 Keith Owens <>

* Upgrade to 2.5.43.
* kdb v2.3-2.5.43-i386-1.

No kdb patch for ia64 until there is a more recent ia64 kernel patch for 2.5.


Starting with kdb v2.0 there is a common patch against each kernel which contains all the architecture independent code plus separate architecture dependent patches. Apply the common patch for your kernel plus at least one architecture dependent patch, the architecture patches activate kdb.

The naming convention for kdb patches is :-

To build kdb for your kernel, apply the common kdb patch which is less than or equal to the kernel v.p.s, taking the highest value of '-n' if there is more than one. Apply the relevant arch dependent patch with the same value of 'vx.y-v.p.s-', taking the highest value of '-n' if there is more than one.

For example, to use kdb for i386 on kernel 2.5.43, apply
kdb-v2.3-2.5.43-common-<n> (use highest value of <n>)
kdb-v2.3-2.5.43-i386-<n> (use highest value of <n>)
in that order.

Use patch -p1 for all patches.

30. Linux 2.5.43-mm2 Released

16�Oct�2002 (1 post) Subject: "2.5.43-mm2"

Topics: Hot-Plugging

People: Andrew Morton,�Randy Hron

Andrew Morton announced:


31. Support For NEC PC-9800 Architecture

17�Oct�2002 (1 post) Subject: "[PATCH][RFC] add support for PC-9800 architecture (1/26) apm"

People: Osamu Tomita

Osamu Tomita posted a bunch of patches, and said, "This patchset adds support for NEC PC-9800 architecture, against 2.5.43."

32. Linux Security Module Bypassing The GPL

17�Oct�2002 (14 posts) Subject: "[PATCH] make LSM register functions GPLonly exports"

Topics: Binary-Only Modules, FS

People: Christoph Hellwig,�Greg KH,�Crispin Cowan,�Linus Torvalds,�Ingo Molnar,�Arjan van de Ven

Christoph Hellwig posted a patch to remove some symbol exports, explaining, "These exports have the power to change the implementations of all syscalls and I've seen people exploiting this "feature". Make the exports GPLonly (which some LSM folks agreed to when it was merged initially to avoid that)." Greg KH replied, "I would really, really, really like to make this change. Unfortunatly, one of the current copyright holders of this file does not agree with it. Crispin, for the benifit of the lkml readers, can you explain why WireX does not want this change?" Crispin Cowan replied:

Here's the monster flame-war we had the last time this issue was debated

My argument against the intent of this change is that no, I do not think we should restrict LSM modules to be GPL-only. LSM is an API for loading externally developed packages of software, similar to syscalls. There is benefit in permitting proprietary modules (you get additional modules that you would not get otherwise) just as there is benefit in permitting proprietary applications (you get Oracle, DB2, and WordPerfect).

My argument against the implementation technique of dropping in these export GPLonly symbols is that my read of the GPL itself means that they have no legal impact. The crux of the matter is whether a *court* finds that LSM is "linking" (in the GPL sense) or is an "interface":

Therefore, the EXPORT_SYMBOL_GPL is just a bunch of useless bloat, with no legal standing what so ever. If kernel module interfaces are held by a court to be linking, then export symbols are redundant. If kernel module interfaces are held by a court to be an interface, then the export symbols are just wrong.

A couple posts later, Linus Torvalds intervened, saying:

Note that if this fight ends up being a major issue, I'm just going to remove LSM and let the security vendors do their own thing. So far

I will re-iterate my stance on the GPL and kernel modules:

There is NOTHING in the kernel license that allows modules to be non-GPL'd.

The _only_ thing that allows for non-GPL modules is copyright law, and in particular the "derived work" issue. A vendor who distributes non-GPL modules is _not_ protected by the module interface per se, and should feel very confident that they can show in a court of law that the code is not derived.

The module interface has NEVER been documented or meant to be a GPL barrier. The COPYING clearly states that the system call layer is such a barrier, so if you do your work in user land you're not in any way beholden to the GPL. The module interfaces are not system calls: there are system calls used to _install_ them, but the actual interfaces are not.

The original binary-only modules were for things that were pre-existing works of code, ie drivers and filesystems ported from other operating systems, which thus could clearly be argued to not be derived works, and the original limited export table also acted somewhat as a barrier to show a level of distance.

In short, Crispin: I'm going to apply the patch, and if you as a copyright holder of that file disagree, I will simply remove all of he LSM code from the kernel. I think it's very clear that a LSM module is a derived work, and thus copyright law and the GPL are not in any way unclear about it.

If people think they can avoid the GPL by using function pointers, they are WRONG. And they have always been wrong.

He replied to himself:

Side note: it should be noted that legally the GPLONLY note is nothing but a strong hint and has nothing to do with the license (and only matters for the _enforcement_ of said license). The fact is:

So the GPLONLY is really a big red warning flag: "Danger, Will Robinson".

It doesn't have any real legal effect on th emeaning of the license itself, except in the sense that it's another way to inform users about the copyright license (think of it as a "click through" issue - GPLONLY forces you to "click through" the fact that the kernel is under the GPL and thus derived works have to be too).

Clearly "click through" _has_ been considered a legally meaningful thing, in that it voids the argument that somebody wasn't aware of the license. It doesn't change what you can or cannot do, but it has some meaning for whether it could be wilful infringement or just honest mistake.

Ingo Molnar added:

one more addition here: as long as those works do not copy any part of the kernel, be that source code or binary code. Ie. they:

There's been a precedent created in the US just two days ago, at the appelate level, that makes certain types of functionality-enhancing 'binary-patching' practices fall under the copyright of the patched work.

Ie. the GPL qualifies even if the main body of the work in question is not derived from the kernel, but the work depends on modifying the kernel. So it's a questionable practice even for non-derived bin-only modules to patch the kernel or modify it in any not originally intended way.

and the well-known issues of:

both can be independently created via the rules of reverse engineering. (whatever they are in the country it's done - but be prepared for the US to attempt to take jurisdiction over your acts, wherever you are ...)

Crispin replied, regarding Linus' intention to remove LSM unless Crispin accepted the patch, "If it comes to that, go ahead and apply the patch. I would far rather have an LSM that requires GPL'd modules than no LSM at all." He added:

Thanks for the clarification, but that still leaves questions. In particular, it is unclear whether a work is "derived" if it includes kernel header files, which is more or less required if you hope to make a module fit the interface.

Note that if we decide that #include of a kernel header file means that a work is derived, then we cause another problem: most Linux applications come under the GPL. glibc #includes some kernel header files, and most Linux applications #include glibc headers, so most applications are #including kernel header files. If #include is the basis for declaring a module to be a derived work of the kernel, then there is some bad news coming for people who like to use Oracle and DB2 on Linux ...

Arjan van de Ven replied, "difference is that glibc only uses the glibc-kernheaders; which on several distros at least are just the data structures and not the inlines. (and the inlines are in #ifdef KERNEL anyway and removed by the preprocessor for userspace)"

33. Linux Kernel conf 1.0 Released

17�Oct�2002 (1 post) Subject: "linux kernel conf 1.0"

People: Roman Zippel

Roman Zippel announced:

Here is now the final release (it's as usual at ). Changes in this release:

Linus, nobody complained about it, so I put it now into your hands. :) The easiest way is probably to use the converter with 'make install KERNELSRC=...', which will convert your current tree.

The generated name is still Kconfig, if you prefer something different, it's easily changable. The name is generated in cml1.y:gen_filename() and only a search&replace in fixup-all.diff is needed.

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.