Kernel Traffic
Latest | Archives | People | Topics
Latest | Archives | People | Topics
Latest | Archives | People | Topics
Home | News | RSS Feeds | Mailing Lists | Authors Info | Mirrors | Stalled Traffic

Kernel Traffic #188 For 13 Oct 2002

By Zack Brown

Table Of Contents

Mailing List Stats For This Week

We looked at 1840 posts in 12108K.

There were 479 different contributors. 266 posted more than once. 226 posted last week too.

The top posters of the week were:

1. Upcoming Feature Freeze By End Of October

30 Sep 2002 - 8 Oct 2002 (32 posts) Subject: "Linux v2.5.40 - and a feature freeze reminder"

Topics: Disks: IDE, FS: ReiserFS, Feature Freeze, Kernel Build System, Networking, USB, Virtual Memory

People: Linus TorvaldsHans Reiser

Linus Torvalds announced 2.5.40 and said:

Merges with all the regular suspects - Al's partitioning, Andrew on VM, USB, networking, sparc, net drivers. And Ingo has been working on fixing up the inevitable details in the thread signal stuff, as well as updating the smp-scalable timer code.

And ISDN, kbuild, ARM, uml...

And a small reminder that we're now officially in the last month of features, and since I'm going to be away basically the last week of October, so I actually personally consider Oct 20th to be the drop-date, unless you've got a really good and scary costume.. So don't try to leave it to the last day.

[ And if that didn't worry you, the following should: I'm perfectly happy with the kernel, and as such whatever features _you_ think are missing might just not weigh too much with me if you then also make the mistake of trying to leave them for the last crunch. I might just take the last day off too ;]

And if it wasn't clear to the non-2.5-development people out there, yes you _should_ also test this code out even before the freeze. The IDE layer shouldn't be all that scary any more, and while there are still silly things like trivially non-compiling setups etc, it's generally a good idea to try things out as widely as possible before it's getting too late to complain about things..

There was no general outcry against the shorter cut-off date, but Hans Reiser did say, "Wouldn't it make more sense, or at least be more fair, to move the deadline in the other direction if you are going on vacation/away? We're going to have trouble getting reiser4 ready before the Halloween date you announced, and we are working long hours as it is. reiser4 is dramatically better and dramatically faster than reiserfs." But there was no reply.

Elsewhere, someone said they'd love to test these heading-toward-stable kernels, but didn't want to risk trashing their filesystem. They asked how likely that would be, and Linus replied:

Personal opinion (and only that): not much chance for a filesystem trashing.

There's more chance of something just not _working_ than of disk corruption. Ie you may find that some driver you need doesn't compile because it hasn't been updated to the new world order yet, for example.

And people still report problems booting, for example, whatever the reason. So make sure you have a working choice in your lilo configuration or whatever.

But from what we've seen lately, there really aren't reports of corrupted disks or anything like that that I've seen. Which is obviously not to say that it couldn't happen, but it's not a very likely occurrence.

That said, I can't set other peoples risk bars for them.

2. LVM Removed From 2.5; Replacements Sought

1 Oct 2002 - 5 Oct 2002 (29 posts) Subject: "[PATCH] Remove LVM from 2.5 (resend)"

Topics: Device Mapper, Disk Arrays: EVMS, Disk Arrays: LVM, Disk Arrays: MD, Disk Arrays: RAID, FS: InterMezzo

People: Alexander ViroAndreas DilgerDave JonesJens AxboeAlan CoxTheodore Y. Ts'oJoe Thornber

Joe Thornber gave a pointer to a large patch removing LVM from the 2.5 tree. Alexander Viro applauded this move, saying the LVM code was completely unmaintained. He added, "Speaking of which, would Intermezzo maintainers care to port the thing to 2.5? If it's abandoned - at least say so ;-/" Andreas Dilger remarked, "One of the Clusterfs developers is now working on updating InterMezzo again..." Elsewhere, someone came back to the LVM question, saying that some kind of logical volume manager was needed in 2.6, even if LVM1 was removed. The poster asked, would LVM2 be included? Dave Jones replied, "No-one suggested 2.6.0 shipping without /something/, but having a dead LVM1 in _2.5_ doesn't help anyone. We've gone 6 months with it being in a broken/uncompilable state, going another month without it isn't a big deal. Getting something in before halloween is however a goal the Sistina folks should be aiming for."

In the course of discussion, the point was made by Jens Axboe and others, that the replacement for any given feature should be provided before the patch to remove that feature. As Jens put it, "No matter the state of lvm, it's much better to day "1, here's the replacement - 2, rip the old one out". What if device mapper for 2.5 really sucks? Maybe it's so bad that we'd rather fix up lvm1? Apparently davej has patches that sort-of makes lvm work. It's not likely, but still :-)" Still, no one seemed overly concerned that LVM was being removed first. They appeared more interested in the general point.

Some folks suggested EVMS as a possible replacement, but Alan Cox said tartly, "The more shit you pile the more likely your compost heap is to collapse. And with some of the stuff in EVMS I don't want to be around when it does." Extolling Device Mapper, he added, "DM is small and clean. It may well be that if we go the DM way (and I think we should) that those bits of EVMS that we want (like cluster) actually come out a lot cleaner than in EVMS itself." But Theodore Y. Ts'o remarked that one reason DM was so clean was because it lacked a lot of needed functionality. He said, "Last I checked it couldn't do RAID 5 or r/w snapshots without completely bypassing its core infrastructure (since you're no longer just doing simple block remapping at that point), and once you add all that stuff, it's likely to become much more complex." But Alan said that there was a perfectly good md driver to handle RAID 5.

Folks continued to advocate for EVMS, and there was much disagreement. One thing everyone agreed on, however, was the need to get something usable into 2.6; some folks felt such a something could be a temporary expedient, while others felt (in Alan's words) "You don't want a substitute in the mean time, because then you have to get rid of it."

3. Linus On Coding Style

1 Oct 2002 - 7 Oct 2002 (26 posts) Subject: "[patch] Workqueue Abstraction, 2.5.40-H7"

People: Linus Torvalds

In the course of discussing a workqueue abstraction patch, Linus Torvalds gave some opinions of coding style issues:

Pease don't introduce more typedefs. They only hide what the hell the thing is, which is actively _bad_ for structures, since passing a structure by value etc is something that should never be done, for example.

The few saved characters of typing do not actually _buy_ you anything else, and only obscures what the thing is.

Also, it's against the Linux coding standard, which does not like adding magic single-letter suffixes to things - that also is the case for your strange "_s" suffix for a structure (the real suffix is "_struct").

Remember: typing out something is not bad. It's _especially_ not bad if the typing makes it more clear what the thing is.

He added in reply to himself:

Btw, just to avoid counter-examples: Linux does use structures and typedefs occasionally to hide and force compiler typechecking on small structures on purpose. We have a few places where we do things like

        typedef struct {
                unsigned int value;
        } atomic_t;

(and similar things for the page table entries etc).

This is done because the things are often really regular scalars, but we use the structure as a strict type checking mechanism. In this case, using a typedef is fine, because we don't actually ever want to _access_ it as a structure, and the typedef provices exactly the kind of information hiding that we need.

But type hiding for a real structure just doesn't make sense, since we use it as a true structure, and hiding information just makes it harder to see.

Elsewhere, he added:

Big things should have big names. That's why "u8" is u8, because it's not just physically small, it also has very little semantics associated with it.

I want those variable declarations to stand out, and make people understand that this is not just a variable, it's a structure, and it may be taking up a noticeable amount of space on the stack, for example.

That's the main issue for me. I don't personally care so much about trying to avoid dependencies in the header files that can also be problematic. That's probably partly because I use fast enough machines that parsing them a few extra times doesn't much bother me, and circular requirements tend to be rare enough not to bother me unduly.

So the thing is a big red warning sign that you're now using a complex data structure, and you should be aware of the semantics that go with it.

4. NUMA Scheduler Patch

1 Oct 2002 - 7 Oct 2002 (10 posts) Subject: "[RFC] Simple NUMA scheduler patch"

Topics: Big O Notation, Scheduler

People: Michael HohnbaumErich Focht

Michael Hohnbaum posted a patch and announced:

Attached is a patch which provides a rudimentary NUMA scheduler. This patch basically does two things:

This has been tested on the IA32 based NUMAQ platform and shows performance gains for kernbench. Various microbenchmarks also show improvements and stickiness of processes to nodes. Profiles show that the kernbench performance improvements are directly attributable to the use of local memory caused by tasks running on the same node through their lifetime.

I will be doing much more testing of this, and likely will be tweaking some of the algorithms based upon test results. Any comments, suggestions, flames are welcome.

Patch applies to 2.5.40 and makes use of the new NUMA topology API. This scheduler change should work on other NUMA platforms with just the definition of the architecture specific macros in topology.h.

Erich Focht replied critically:

it's a start. But I'm afraid a full solution will need much more code (which is one of the problems with my NUMA scheduler patch).

The ideas behind your patch are:
1. Do initial load balancing, choose the least loaded CPU at the beginning of exec().
2. Favor own node for stealing if any CPU on the own node is >25% more loaded. Otherwise steal from another CPU if that one is >100% more loaded.

1. is fine but should ideally aim for equal load among nodes. In the current form I believe that the original load balancer does the job right after fork() (which must have happened before exec()). As you changed the original load balancer, you really need this initial balancing.

2. is ok as it makes it harder to change the node. But again, you don't aim at equally balanced nodes. And: if the task gets away from the node on which it got its memory, it has no reason to ever come back to it.

For a final solution I believe that we will need targets like:
(a) equally balance nodes
(b) return tasks to the nodes where their memory is
(c) make nodes "sticky" for tasks which have their memory on them, "repulsive" for other tasks.
But for a first attempt to get the scheduler more NUMA aware all this might be just too much.

With simple benchmarks you will most probably beat the plain O(1) scheduler on NUMA if you implement (a) in just 1. and 2. as your node is already somewhat "sticky". In complicated benchmarks (like a kernel compile ;-) it could already be too difficult to understand when the load balancer did what and why...

It would be nice to see some numbers.

Michael agreed that much more was needed for a full solution, but he thought his patch was a good start that could be extended over time. He argued that his patch would already produced balanced nodes on a loaded system, though he agreed with Erich's other points. He added, "I've got kernbench numbers and profile results from 2.5.38-mm1" [...] "These show a modest performance benefit, but don't provide detail on process to node mapping."

The two of them (and others) proceeded to have a polite discussion about the direction of their respective work, and how best to integrate NUMA scheduling patches into the kernel.

5. BitKeeper Tips

2 Oct 2002 - 4 Oct 2002 (42 posts) Subject: "EVMS Submission for 2.5"

Topics: Disk Arrays: EVMS, FS: JFS, USB, Version Control

People: Greg KHLinus Torvalds

In the course of discussing possible EVMS inclusion into 2.5, Greg KH observed:

this is just my opinion of how to use BitKeeper, not the "rule":

You can use BitKeeper for kernel development in two ways:

Linus Torvalds, close at hand, replied:

I think this is a pretty good point, and is something that I don't think anybody has ever really said explicitly before.

Some of the BK usage documentation (or "hints") by Jeff clearly imply this behaviour, but it's not really stated explicitly anywhere.

Also note that using multiple trees is pretty easy - you _can_ easily do development in the "export" tree, if you just make sure that you only do one kind of development. And then you have a separate "test" tree that is a "throw-away combination tree" which just pulls all the other trees and has the combination of all the different work trees.

That multi-tree approach has advantages quite outside of merging cleanly: it means that when trouble happens, and something doesn't work, it's really easy to test out other changes.

I personally often use the multi-tree approach myself when merging bigger changes (especially if there are other changes that are in the same area): before I apply something big, I clone my regular tree (often down to a known version, like the last release), and apply those changes in that separate tree.

Then I build and test that separate tree before I merge it into my "final merge" tree - it makes it easier to see whether problems are due to a specific line of patches, or whether it might be some interaction between different changes.

He went on:

One reason it's so easy to merge with the USB people (and with Jeff and David and a number of others too, for that matter) is exactly the fact that when I get an email that says "pull this tree to get these USB changes", that is all I get. Not "random support changes to other parts of the kernel that I also used on my tree".

If I don't get a clean BK tree to pull from, I just cannot pull it. I end up applying the diffs by hand instead, at which point when I push out my end result, the original source of the patches does _not_ get a clean BK tree that matches mine, but instead gets a BK tree that has the changes TWICE, in addition to all the crud it already had.

Which now makes it doubly hard to see which parts I applied, and which ones I didn't - BK will usually have successfully merged the trees, but you don't actually get any real "source control". You only get a messy tree.

As a result, such a tree is even _less_ useful than it was last time, and definitely will never be pulled by me ever again, and the poor kernel developer ends up not getting any of the real advantages of BK at all.

He recommended BitKeeper users not only use two BitKeeper trees, but many:

In fact, _most_ people that merge with me using BK seem to use more than one tree already (some developers are very specialized and only have the one tree: JFS and ARM come to mind).

I think it's very much a "getting used to the experience". Some people don't like it, and that's fine - I have absolutely no problem applying clean patches either, and some of the major kernel developers have never used a BK tree to merge with me (Andrew, Viro, Alan, Ingo..) and it hasn't been a problem.

I personally think there is a very simple rule to using BK: if you're doing development, and you only have one tree, you're doing something wrong. The "single tree" approach is fine if your use of BK is really more of a "anonymous CVS" replacement - you use BK only to track somebody elses tree and build that. But if you do real development, you should have multiple trees, or you're not really using BK as a SCM.

6. Support For The Creative Audigy Sound Card

3 Oct 2002 - 4 Oct 2002 (2 posts) Subject: "ALSA or OSS: Creative Audigy"

Topics: Sound: ALSA, Sound: Creative Audigy, Sound: MIDI, Sound: OSS, Sound: SoundBlaster, Sound: WaveTable

People: Takashi Iwai

Stephen Marz asked if there were any plans to support the Creative Audigy sound card; and Takashi Iwai replied:

it is already supported on both. it works as an emu10k1 (SB Live) compatible, i.e. no new feature such like 24bit support.

both drivers have advantage and disadvantage. OSS driver has much better DSP manager, while ALSA driver supports WaveTable MIDI.

7. Developers Argue Over Devfs

3 Oct 2002 - 4 Oct 2002 (7 posts) Subject: "[BK PATCH] minor devfs cleanup for 2.5.40"

Topics: FS: devfs, FS: initramfs, FS: ramfs, FS: rootfs

People: Greg KHRichard GoochChristoph Hellwig

Greg KH offered, "Here's a changeset from Christoph Hellwig that removes some unneeded code from the kernel core. This was leftover from before devfs became part of the main kernel tree, and was trying to do some naming fixups in kernelspace. If anyone still has machines using these names, their startup scripts should be modified to use the "standard" devfs names." But Richard Gooch exclaimed:

NO! Dammit, you'll break everyone who is using these compact names to mount the root FS. Look more closely at the code you're trying to remove, and you'll see it's *not* used to avoid work in startup scripts. It's only used to create the devfs entry for the root FS.

This change is gratuitous. The code is __init code anyway, so doesn't contribute to bloat. And forcing people to migrate to the longer names isn't reasonable, as it chews up precious space on the kernel command line. I've had times where I ran out of space when I had too many options.

Linus, please don't apply.

Christoph Hellwig protested that the compact names were never in the 2.5 mainline sources, and that users should use the new devfs names, plain linux names, or hex values. Richard pointed out that the names had been in 2.4 for a long time, and removing them would cause lots of users to experience boot-time kernel panics. Christoph replied, "They have never been the devfs names in_any_ kernel. Linus made you change to saner names before merging devfs (saner code would also have been a good idea, btw..). Anyway, 2.5 is going to initramfs, so feel free to put devfsd into your initramfs." Richard replied:

The convenience names for the root FS *have* been in the kernel since before 2.4.x. I agree with the initramfs approach: that's been my plan for handling the rootFS compatibility names (put a mini devfsd into initramfs). But until all the infrastructure for that is ready, you can't just go around breaking features people rely on. Especially where there is no benefit to breaking it.

If you really feel strongly about it, and don't want to wait for devfsd to be added to initramfs, by all means move the current code (or the moral equivalent) to initramfs. But you'll have to wait for initramfs to be available and for it to be the default.

There was no resolution to the discussion.

8. Support For 3Com HomeConnect USB Camera

3 Oct 2002 - 8 Oct 2002 (18 posts) Subject: "Vicam/3com homeconnect usb camera driver"

Topics: USB

People: Greg KH

John Tyner posted a patch against 2.4.19, to implement a driver for the 3Com HomeConnect USB Camera. Greg KH offered to add it to 2.5 if John would port his patch to that tree; John said he'd get right to work, and a couple days later posted the port.

9. Native POSIX Thread Library 0.2 Released

4 Oct 2002 - 9 Oct 2002 (6 posts) Subject: "[ANNOUNCE] nptl 0.2"

Topics: POSIX, SMP, Version Control

People: Ulrich DrepperJ.A. MagallonIngo MolnarH.J. LuLinus Torvalds

Ulrich Drepper announced:

Now that the Linux kernel is once again able to run all the tests we have and since glibc 2.3 was released it was time for a new code drop. I've uploaded the second code drop for the Native POSIX Thread Library:

You need

Compiling glibc should proceed smoothly. But there are a number of tests which fail, mostly because some functionality is missing in glibc. Ignore those errors. It is only important that all tests in nptl/ are passing. Run

make subdirs=nptl check

to run all thread tests.

This version features several improvements:

The white paper hasn't yet been updated. It's still available at

This release should be ready for some serious testing. I know it is hard to compile which I why I'm looking into providing binary RPMs. They can be used on non-critical systems. I'll only be able to provide binaries for RHL8 based systems, though, and the kernel still must be installed separately.

The next steps will include:

Interested parties are once again invited to join the mailing we created:

Go to

to subscribe, unsubscribe, or review the archive.

J.A. Magallon was concerned about testing this, if it required Linus Torvalds' latest BitKeeper snapshot. He asked, "could you state what new kernel features are needed (futexes, cpu-affinity syscalls, signalling changes...). Perhaps people can use 2.4 -ac or -aa trees." But Ingo Molnar replied:

too many to list, really. It's more than 60 separate patches that went into 2.5 in the past 2 months that implement all the necessery infrastructure for NPTL-style 1:1 threading. Futexes had to be fixed too, so it's not like you could use the existing 2.4 futex patch for NPTL. I'll attempt a 2.4 backport of all the threading bits within the next couple of weeks, but it's not a matter of a couple of hours ...

but, 2.5 isnt all that bad these days, and Arjan is currently working on 2.5 kernel rpms, to make it even easier to try out. (it will be announced to phil-list once he's done.)

10. LKCD For 2.5.40 Released

4 Oct 2002 (3 posts) Subject: "[ANNOUNCE] LKCD for 2.5.40"

People: Matt D. RobinsonRandy Dunlap

Matt D. Robinson announced:

These are the patches (9 in all) for the Linux Kernel Crash Dump modifications for 2.5. This allows crash dumps to be built as a module in the kernel and also includes a breakdown of a few of the changes needed in the kernel. The current version will allow for block dumping, and has the ability to readily integrate network dumping (a la Red Hat).

The big debatable issue I can see right away is the dump_in_progress addition to schedule(), which can certainly be moved out or modified to appease people wanting a tight scheduler loop.

Please accept these patches or provide feedback on how we can modify them for acceptance.

Randy Dunlap had some minor technical suggestions, and also pointed out:

Who do you want to accept these patches? If it's Linus, you should send them to him.

Documentation/SubmittingPatches doesn't say so, but lately it's become quite common and desirable to use diffstat output above patches to summarize the files modified and how much they are modified.

11. Updated NatSemi SCx200 Patches For 2.4

5 Oct 2002 (1 post) Subject: "Updated NatSemi SCx200 patches for Linux-2.4"

Topics: Version Control

People: Christer Weinigel

Christer Weinigel offered:

here's a merge of my SCx200 patches with Linux-2.4 from the bitkeeper tree. I'm waiting for Linus to apply the 2.5 patch before submitting this to Marcelo again, but I wanted to post this anyway. Please comment if there is anything strange with these patches.

The patch is also available as a bitkeeper with:

bk pull bk://

12. Patch Submission Policies

5 Oct 2002 (2 posts) Subject: "[BK 1/6] 2.5.x Bluetooth subsystem update. Core."

Topics: USB, Version Control

People: Linus TorvaldsGreg KH

In response to a BitKeeper patch, Linus Torvalds remarked:

_please_ do this the regular way next time. There's even a script to help you do it in linux/Documentation/BK-usage/bk-mak-sum, which does it all for you for BK patches.

(many people end up doing their own thing, you don't have to use that particular script, of course. But the important thing I want is that the _email_ should contain enough information to make a good first pass judgement on what the patch does, and in particular it is important for me to see what a "bk pull" will actually change.)

That's why the "diffstat" is important to me if I do a BK pull - and why I want to see the patches as plaintext if I apply stuff to generic files..


For optimal exposure, do both - this is what Greg KH does for USB stuff (he sends the BK email to me and to the kernel list, and sends individual patches to the kernel list only). Which really helps the people who don't want to use BK for some reason.

13. Memory Management Updates

6 Oct 2002 - 9 Oct 2002 (17 posts) Subject: "2.5.40-mm2"

Topics: FS: sysfs, Kernel Release Announcement

People: Andrew MortonPeter Chubb

Andrew Morton announced 2.5.40-mm2:


14. Backporting CPU Accessor Functions To 2.4

6 Oct 2002 (3 posts) Subject: "[PATCH] 2.4: introduce get_cpu() and put_cpu()"

People: Robert LoveMarcelo TosattiKasper Dupont

Robert Love said to Marcelo Tosatti:

In 2.5, it is unsafe to assume the current processor does not change out from under you - thus you must be atomic when calling smp_processor_id(). We introduced the get_cpu() and put_cpu() methods to provide a safe way to access the current processor.

This patch back-ports those interfaces to 2.4. Note they do nothing special: get_cpu() simply returns smp_processor_id() and put_cpu() is a no-op. But this will allow easier back-porting from 2.5 and common code-base for drivers, etc. It also does not hurt to be explicit that you do not want the processor to change.

As an example, I converted one use of smp_processor_id() to the new interface.

Patch is against 2.4.20-pre9, please apply.

Kasper Dupont found a bug in Robert's implementation, and Robert quickly sent an updated patch.

15. The Future Of bcopy()

7 Oct 2002 - 8 Oct 2002 (10 posts) Subject: "bcopy()"

Topics: FS: XFS

People: David HowellsLinus TorvaldsChristoph HellwigStan BubrouskiKai Henningsen

David Howells said:

The implementation of bcopy() in lib/string.c (and some other places such as the XFS header files) is incorrect as it implements bcopy as memcpy. This is wrong: bcopy should be the equivalent of memmove (which handles overlapping areas correctly).

I've dicussed it with a number of people, and the general consensus seems to be that it should be nuked entirely? Do you agree?

Linus Torvalds replied:

I agree. bcopy should just DIE. Some architectures may have historical trouble with gcc emitting bcopy for structure assignments (and that's definitely a memcpy with no overlap), but I think that's long gone (I know gcc on alpha used to do this several years ago).

XFS seems to be a big user of bcopy, though..

He added in a subsequent post:

I will not apply a patch that removes bcopy() in the name of "cleanliness", if it then results in a number of modules just adding their own

#define bcopy(a,b,c) memcpy(b,a,c)

because then the whole cleanup would be pointless - it would just make some modules even uglier than they were before.

So I'd much rather see the XFS etc code moved away from bcopy() first, because that's the _real_ cleanup. The library code isn't all that ugly in comparison.

Christoph Hellwig replied, "The lowlevel XFS code tries to stay in sync as much as possible with the IRIX codebase to make maintaince easier (we're a very small team..). It could be removed, but I don't think it would help.." Linus said:

Could somebody drag the Irix team kicking and screaming into the 1980's, please?

I realize it might be quite painful for them, but maybe you could buy them a disco tape, so they'd feel a little bit more at home.

Linus "Stayin' alive, stayin' alive" Torvalds

Stan Bubrouski said, "If it were that simple I'm sure it would have been done long ago, no?" But Kai Henningsen replied:

How can it *not* be that simple?

No matter if you think bcopy should work for overlapping memory or not, there is a replacement standard function (by the 1989 ANSI C standard, so maybe the 1980's are not quite modern enough) that does exactly that, with nothing but rearranged parameters.

That's a purely mechanical change, on the same level as the kernel janitor stuff - hell, easier than the kernel janitor stuff.

I expect the reason it hasn't been done in Irix kernel code is simly that there was no real need to do it. I certainly do not imagine there's anything *hard* about it.

Hell, you could just use the #define method to map an XFS memcpy (or memmove) onto the Irix kernel library bcopy!

No, this is politics, not technical. (On both sides, of course.)

16. Tagged Command Queueing Reimplemented For Current 2.5 IDE

7 Oct 2002 - 8 Oct 2002 (3 posts) Subject: "[patch] ide tcq support, 2.5.40-bk"

Topics: Disks: IDE, Version Control

People: Jens AxboeMorten HelgesenLinus Torvalds

Jens Axboe posted a patch and said, "Tagged command queueing support for IDE is available again. It has a few rough edges from a source style POV, nothing that should impact stability though. Patch against 2.5.40-BK attached." Morten Helgesen hammered on the patch for awhile on 2.5.41 but couldn't break it, and said, "I`d like this to go into mainline (again) - when Jens feels the time is right, of course." Jens thanked him for the testing, and said he'd already sent it in to Linus Torvalds.

17. Linux Plug and Play Layer 0.6 For 2.5.40

7 Oct 2002 (1 post) Subject: "[ANNOUNCE][PATCH] Linux Plug and Play Layer V0.6 - 2.5.40"

Topics: FS: driverfs, Modems, Power Management: ACPI

People: Adam Belay

Adam Belay announced:

Linux Plug and Play Support V0.6

The included patch is essentially a Linux Plug and Play Support rewrite. It contains many significant improvements, including the following:

  1. A Global Plug and Play Layer
  2. A complete Plug and Play BIOS driver
  3. Driver Model Integration
  4. A powerful global resource configuration interface
  5. Automatic resource allocation for needed devices
  6. A PnP device name database

And many more improvements.

The code is relatively stable and I encourage anyone who's curious to try it out. Currently only the serial driver has been converted to the new APIs but that includes just about every modem. Patches to convert other drivers are welcome. Feel free to send bug reports, questions, comments, etc.

18. Linux 2.5.41 Released

7 Oct 2002 - 8 Oct 2002 (17 posts) Subject: "Linux v2.5.41"

Topics: Virtual Memory

People: Linus TorvaldsRobert Love

Linus Torvalds announced 2.5.41, "Tons of stuff.?Mucho merges with the "A-Team" (Alan, Al, Alexey, Andrew, Anton, Arjan, Arnaldo and Art), but the "M-Team" (Maksim, Marcel, Martin's and Mike) is a close runner up. The J's are doing well too." He replied to himself:

Oh, and I totally forgot ..

The merge from Andrew merged in various VM counter updates, which change /proc accounting in ways that make some of the system monitoring stuff unhappy. In particular, you'll find "vmstat" dumping core, and "top" has a few glitches too.

You can fix all of this by just upgrading to a newer "procps" package. Rik maintains a procps-2.0.9 (many of the stats were his) at

I don't think there are ready-made binary packages, but maybe some enterprising and helpful - and trustworthy - soul can do that and get vendors to add it to their upgrade list (or at least make it available in contrib).

Robert Love made some binary RPMs and gave a link.

19. driverfs Changing Its Name; New Name Unknown

7 Oct 2002 (8 posts) Subject: "[bk/patch] Rename driverfs to kfs"

Topics: FS: driverfs

People: Patrick MochelH. Peter Anvin

Patrick Mochel announced:

It's the incredible mutable filesystem. As was talked about at the Kernel Summit in Ottawa, and as has been threatened in the past three months, here is the patch to rename driverfs to kfs.

It's really simple, and is basically a global search and replace of all the direct users of driverfs (so far only the driver model and acpi), as well as the documentation.

As a result of this, you must of course update your /etc/fstab to mount kfs instead of driverfs.

H. Peter Anvin said he'd prefer calling it kernelfs or kernfs, and Patrick asked, "Does Linus have an opinion? He apparently doesn't love me anymore, so I'm not sure that he's even paying attention, or he still agrees with the change.."

20. Adding Extended Attributes To ext2 And ext3

8 Oct 2002 - 9 Oct 2002 (11 posts) Subject: "[RFC] [PATCH 1/4] Add extended attributes to ext2/3"

Topics: Access Control Lists, Extended Attributes, FS: XFS, FS: ext2, FS: ext3, Feature Freeze

People: Theodore Y. Ts'oChristoph HellwigAndreas GruenbacherEd TomlinsonAndrew Morton

Theodore Y. Ts'o announced:

This is the first of four patches which add extended attribute support to the ext2 and ext3 filesystems. It is a port of Andreas Gruenbacher's patches, which have been well tested and in a number of distributions (including RH 8, if I'm not mistaken) already. I just ported it to 2.5 (these patches are versus 2.5.40). As always, since I touched the code last, any problems in it are my fault. :-)

These patches are prerequisite for the port of the Andreas Gruenbacher's ACL patches to 2.5, which I'm currently working on. But given the short time-frame before feature freeze, I'd like to get these out for review ASAP. Please comment and bleed on them.

Christoph Hellwig replied that Red Hat had backed out Andreas' patches after a few BETA releases. He suggested using "Ed Tomlinson's much saner interface that adds a third callbackj to kmem_cache_t (similar to the Solaris implementation) instead. Doing this outside slab is not a good idea (and XFS currently does it too - in it's own code which should be replaced with Ed's one)." Theodore asked for a pointer to this code, and various folks (including Ed) said it was in Andrew Morton's tree, at Various folks started working on those patches instead.

21. Linux Test Project 20021008 Released

8 Oct 2002 - 9 Oct 2002 (3 posts) Subject: "[ANNOUNCE] Linux Test Project October Release Available"

Topics: Bug Tracking, Version Control

People: Robert Williamson

Robert Williamson announced:

The Linux Test Project test suite LTP-20021008.tgz has been released. Visit our website ( to download the latest version of the testsuite, and for information on test results on pre-releases, release candidates & stable releases of the kernel. There is also a list of test cases that are expected to fail, please find the list at (

The highlights of this release are:

We encourage the community to post results, patches, or new tests on our mailing list, and to use the CVS bug tracking facility to report problems that you might encounter. More details available at our web-site.

22. IPMI V. 4 Released

8 Oct 2002 (1 post) Subject: "[PATCH] IPMI driver for Linux, version 4"

People: Corey Minyard

Corey Minyard asked:

I have put a new version of the IPMI driver on my home page ( that fixes a bug. A previous unannounce version is there (v3) that adds IPMB broadcast support and fixes a bug. If you are using this driver, you want to update to the newest version. These are only supplied as a patches against the previous version since the patches are small and apply to all kernel versions. If someone wants a full patch, I can do that, too.

I was toying with the idea of adding a socket interface to the IPMI driver. This way, it would naturally handle separation of addressing and data, and it wouldn't take up a character device. I think I could map everything the driver does into standard network calls, and the IPMB bus is sort of a network, anyway. Does anyone have any opinions on this?

PS - 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

23. SCx200 Support In 2.4

8 Oct 2002 (1 post) Subject: "Updated SCx200 patches for 2.4"

Topics: I2C

People: Christer WeinigelMarcelo Tosatti

Christer Weinigel posted a patch and said to Marcelo Tosatti:

My SCx200 patches just turned up in Linux-2.5.41, so I would like to submit them for 2.4 too so that 2.4 and 2.5 are synced.

The patch adds support for the National Semiconductor SCx200 processor family to Linux 2.4. The patch consists of the following drivers:

arch/i386/kernel/scx200.c -- give kernel access to the GPIO pins

drivers/chars/scx200_gpio.c -- give userspace access to the GPIO pins
drivers/chars/scx200_wdt.c -- watchdog timer driver

drivers/i2c/scx200_i2c.c -- use any two GPIO pins as an I2C bus
drivers/i2c/scx200_acb.c -- driver for the Access.BUS hardware

drivers/mtd/maps/scx200_docflash.c -- driver for a CFI flash connected to the DOCCS pin

If they look ok to you, please apply.

24. linux-2.5.41uc0 Released

9 Oct 2002 (1 post) Subject: "[PATCH]: linux-2.5.41uc0 (MMU-less support)"

Topics: Kernel Build System, Networking, Virtual Memory

People: Greg Ungerer

Greg Ungerer announced:

The latest set of MMU-less support patches are up. You can get the all-in-one patch at:

Change log:

  1. patched against 2.5.41
  2. reworked build system (support new kbuild changes)
  3. switch to workqueue's in serial and ethernet drivers
  4. started import Christop Hellwigs MM changes

You can get smaller patches here:

25. ACL Support For ext2 And ext3

9 Oct 2002 (1 post) Subject: "[RFC] [PATCH 0/5] ACL support for ext2/3"

Topics: Access Control Lists, Extended Attributes, FS: NFS, FS: XFS, FS: ext2, FS: ext3

People: Theodore Y. Ts'oAndreas Gruenbacher

Theodore Y. Ts'o announced:

The following patch set adds ACL support to the ext2/3 filesystem. It is a port of the 0.8.50 patches from Andreas Gruenbacher. It requires the Extended Attribute patches which I had sent earlier as a pre-requisite, and represents the 2nd of 3 sets of patches from the code. (The first set was the EA patches; this is the second set of patches; and the third set of patches adds ACL support to NFS, so that the NFS server respects the ACL set on the filesystem.)

Some of these patches in this set are shared in common with the XFS filesystem, and are needed for ACL support in XFS as well. These patches are versus 2.5.40, and still reflect the original design decision of allowing ext2 and ext3 ACL support to be available as separate standalone modules. (See the discussion of the EA patches about whether or not this makes sense.)

Please comment/bleed on these patches.







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.