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 #250 For 4 Feb 2004

By Zack Brown

Table Of Contents

Mailing List Stats For This Week

We looked at 2517 posts in 13250K.

There were 675 different contributors. 358 posted more than once. 233 posted last week too.

The top posters of the week were:

1. Some Comparison Of devfs And udev

30 Dec 2003 - 11 Jan 2004 (172 posts) Archive Link: "udev and devfs - The final word"

Topics: Disks: SCSI, FS: devfs, FS: sysfs, Hot-Plugging, Ottawa Linux Symposium, PCI, Sound, USB

People: Greg KHPrakash K. Cheemplavam

Greg KH said:

(This text can be found at for those who want to link to it. I'll also update it with info based on the thread I know is going to spawn from this post...)

Executive summary for those too lazy to read this whole thing:

I don't care about devfs, and I don't want to talk about it at all anymore. If you love devfs, fine, I'm not trying to tell anyone what to do. But you really should be looking into using udev instead. All further email messages sent to me about devfs will be gladly ignored.

First off, some background. For a description of udev, and what it's original design goals were, please see the OLS 2003 paper on udev, available at:
and the slides for the talk, available at:
The OLS paper can also be found in the docs/ directory of the udev tarball, available on in the /pub/linux/utils/kernel/hotplug/ directory.

In that OLS paper, I described the current situation of a static /dev and the current problems that a number of people have with it. I also detailed how devfs tries to solve a number of these problems. In hindsight, I should have never mentioned the word, devfs, when talking about udev. I did so only because it seemed like a good place to start with. Most people understood what devfs is, and what it does. To compare udev against it, showing how udev was more powerful, and a more complete solution to the problems people were having, seemed like a natural comparison to me.

But no more. I hereby never want to compare devfs and udev again. With the exception of this message...

The Problems:

  1. A static /dev is unwieldy and big. It would be nice to only show the /dev entries for the devices we actually have running in the system.
  2. We are (well, were) running out of major and minor numbers for devices.
  3. Users want a way to name devices in a persistent fashion (i.e. "This disk here, must _always_ be called "boot_disk" no matter where in the scsi tree I put it", or "This USB camera must always be called "camera" no matter if I have other USB scsi devices plugged in or not.")
  4. Userspace programs want to know when devices are created or removed, and what /dev entry is associated with them.

The constraints:

  1. No policy in the kernel!
  2. Follow standards (like the LSB)
  3. must be small so embedded devices will use it.

So, how does devfs stack up to the above problems and constraints:


  1. devfs only shows the dev entries for the devices in the system.
  2. devfs does not handle the need for dynamic major/minor numbers
  3. devfs does not provide a way to name devices in a persistent fashion.
  4. devfs does provide a deamon that userspace programs can hook into to listen to see what devices are being created or removed.


  1. devfs forces the devfs naming policy into the kernel. If you don't like this naming scheme, tough.
  2. devfs does not follow the LSB device naming standard.
  3. devfs is small, and embedded devices use it. However it is implemented in non-pagable memory.

Oh yeah, and there are the insolvable race conditions with the devfs implementation in the kernel, but I'm not going to talk about them right now, sorry. See the linux-kernel archives if you care about them (and if you use devfs, you should care...)

So devfs is 2 for 7, ignoring the kernel races.

And now for udev:


  1. using udev, the /dev tree only is populated for the devices that are currently present in the system.
  2. udev does not care about the major/minor number schemes. If the kernel tomorrow switches to randomly assign major and minor numbers to different devices, it would work just fine (this is exactly what I am proposing to do in 2.7...)
  3. This is the main reason udev is around. It provides the ability to name devices in a persistent manner. More on that below.
  4. udev emits D-BUS messages so that any other userspace program (like HAL) can listen to see what devices are created or removed. It also allows userspace programs to query it's database to see what devices are present and what they are currently named as (providing a pointer into the sysfs tree for that specific device node.)


  1. udev moves _all_ naming policies out of the kernel and into userspace.
  2. udev defaults to using the LSB device naming standard. If users want to deviate away from this standard (for example when naming some devices in a persistent manner), it is easily possible to do so.
  3. udev is small (49Kb binary) and is entirely in userspace, which is swapable, and doesn't have to be running at all times.

Nice, 7 out of 7 for udev. Makes you think the problems and constraints were picked by a udev developer, right? No, the problems and constraints are ones I've seen over the years and so udev, along with the kernel driver model and sysfs, were created to solve these real problems. I also have had the luxury to see the problems that the current devfs implementation has, and have taken the time to work out something that does not have those same problems.

So by just looking at the above descriptions, everyone should instantly realize that udev is far better than devfs and start helping out udev development, right? Oh, you want more info, ok...

Back in May 2003 I released a very tiny version of udev that implemented everything that devfs currently does, in about 6Kb of userspace code:

Yes, that's right, 6Kb. So, you are asking, why are you still working on udev if it did everything devfs did back in May 2003? That's because just managing static device nodes based on what the kernel calls the devices is _not_ the primary goal of udev. It's just a tiny side affect of it's primary goal, the ability to never worry about major/minor number assignments and provide the ability to achieve persistent device names if wanted.

All the people wanting to bring up the udev vs. devfs argument go back and read the previous paragraph. Yes, all Gentoo users who keep filling up my inbox with smoking emails, I mean you.

So, how well does udev solve it's goals:

So, convinced already why you should use udev instead of devfs? No. Ok, fine, I'm not forcing you to abandon your bloated, stifling policy, nonextensible, end of life feature if you don't want to. But please don't bother me about it either, I don't care about devfs, only about udev.

This is my last posting about this topic, all further emails sent to me about why devfs is wonderful, and why are you making fun of this wonderful, stable gift from the gods, will be gleefully ignored and possibly posted in a public place where others can see.

A lot of folks off-list, and Prakash K. Cheemplavam publically, replied to Greg on behalf of Gentoo users, saying (as Prakash put it), "I am one of those nasty gentoo users and still use devfs, but I want to switch asap, as I found a thread in gentoo forums about it and furthermore tend to do experiments with my installation. So not all gentoo users are bad users. ;-) I really appreciate your work and hope you will find more time in developing udev instead of wasting time (though it was quite interesting for me to read your text) with arguing for it. So I hope when I do the transition it goes smoothly, but even if not, I won't bash onto your head. ;-)" To this and the similar private email, Greg replied, "By no means did I mean to disparage all Gentoo users, just the ones that keep bothering me with this pointless argument. In fact, now that I know Gentoo works without devfs, I'm considering putting it on an old laptop I have around here..."

There followed quite a bit of discussion, but not much on the actual issue of devfs vs. udev.

2. Linux 2.4.24 Released

5 Jan 2004 - 11 Jan 2004 (14 posts) Archive Link: "linux-2.4.24 released"

People: Marcelo Tosatti

Marcelo Tosatti announced 2.4.24, saying it was the same as 2.4.24-rc1.

3. ALSA 1.0.1 Released

8 Jan 2004 - 13 Jan 2004 (6 posts) Archive Link: "[PATCH] ALSA 1.0.1"

Topics: Sound: ALSA, Sound: OSS, USB, Version Control

People: Jaroslav KyselaJoshua Kwan

Jaroslav Kysela announced:

The ALSA 1.0.1 code for 2.6 kernels is available. I think that this update might be included into -mm or standard 2.6 kernels.


bk pull

The GNU patch is available at:


Joshua Kwan reported, "I've tried this code with 2.6.1-mm1 and it results in my speakers emitting a small high pitched noise when it's not busy playing audio, using the intel8x0 driver. I'm using the onboard sound on my nForce2 based motherboard." A couple of posts later, he added:

When the CPU is under load, the buzzing disappears.
When something else is using /dev/dsp, the buzzing disappears.
When I reboot to 2.6.1-rc1-mm1, the buzzing disappears ;)

4. Real-Time Interrupts

8 Jan 2004 - 11 Jan 2004 (7 posts) Subject: "[announcement, patch] real-time interrupts for the Linux kernel"

Topics: Real-Time

People: Bernhard Kuhn

Bernhard Kuhn said:

a new patch that adds hard real time support to the linux kernel (worst case interrupt response time below 5 microseconds):

The proposed "real time interrupt patch" enables the linux kernel for hard-real-time applications such as data aquisition and control loops by adding priorities to interrupts and spinlocks.

The following document will describe the patch in detail and how to install it:

The patch and a demo application can be downloaded from:

Voicu Liviu asked if this would be useful for a normal desktop, and Bernhard replied:

I don't think that real time interrupts are usefull for a desktop environment: here, even interrupt latencies below one millisecond should be more than good enough for streaming/multimedia applications and games - if your specific application is not "fast" or "reactive" enough, i would tend to say that it is not the fault of the linux kernel and it's the implementation of the application itself or one of the related kernel drivers that needs improovment. If you recognize interrupt response times higher than a millisecond with a standard linux kernel, then there is definitly a bad device driver or something is broken with your hardware.

The real time interrupt patch is mostly intended to be used in control loop and data aquisition applications where higher latencies or jitters higher than a few mirocseconds could have catastrophic consequences. However, i can imagine that it makes sense to use this patch for some very special networking devices where the kernel might sometimes not be able to response quick enough because it is just processing an interrupt of type SA_INTERRUPT that takes too much time. But in these cases, i guess it's simpler to fix that other device driver (by moving parts of the interrupt handler to a tasklet) rather than introducing real time interrupts - the only problem with this variant is that for oftenly changing hardware configurations, you can never be sure if you catched all "longest execution paths" and you may end up spending most of your time improving other device drivers.

BTW.: having interrupt priorities is only the first step to make the kernel hard real time aware. The next step would be to make the kernel scheduler re-entrentable, so that a user space application related to a high priority interrupt could run at a higher priority than a low level interrupt service routine (low priority interrupts are disabled while the high priority application is running) - this scheme is pretty similar to LXRT, except that the kernel scheduler is used instead of an external dispatcher. But just as like as with LXRT, you only have a very limited set of system calls and you can easly lock up your system when an application takes 100% of the CPU.

5. Linux 2.6.1 Released

8 Jan 2004 - 13 Jan 2004 (6 posts) Archive Link: "Linux-2.6.1"

Topics: Kernel Release Announcement, Version Control

People: Linus Torvalds

Linus Torvalds announced 2.6.1, saying:

Ok, the diffs from -rc3 are minimal, most noticeably the (very _very_ hard to trigger, but nasty if you ever did) fork() race that Ingo found.

I'm going to be in Australia (and on airplanes) for the week, but we're all in the capable hands of Andrew, so why worry? The fact that I'm fleeing the country should in no way be construed as anything sinister at all, no siree. Nope. I'm innocent, and nobody saw me do it.

The full changelog is getting uploaded right now along with the release, and the BK trees have already been pushed.

6. Linus 2.6.1-mm1 Released; Framebuffer Development Problems

9 Jan 2004 - 15 Jan 2004 (37 posts) Archive Link: "2.6.1-mm1"

Topics: Disks: IDE, FS: NFS, FS: sysfs, Framebuffer, Kernel Release Announcement, PCI, Sound: ALSA, Virtual Memory

People: Andrew MortonPrakash K. CheemplavamThomas WinischhoferLinus TorvaldsAdrian BunkJames Simmons

Andrew Morton announced 2.6.1-mm1, saying:

Prakash K. Cheemplavam replied, "could it be that you took out /or forgot to insterst the work-around for nforce2+apic? At least I did a test with cpu disconnect on and booted kernel and it hang. (I also couldn't find the work-around in the sources.) I remember an earlier mm kernel had that workaround inside." Andrew replied, "I discussed it with Bart and he felt that it was not a good way of fixing the problem. I'm not sure if he has a better fix in the works though.."

Elsewhere, Adrian Bunk reported some sisfb linking errors, and Thomas Winischhofer replied, "The version of sisfb in 2.6 vanilla is from stone-age. This is has been fixed a long time ago in my current development version (and will be in 2.4 as soon as Marcelo applies my patch which I sent him about a week ago). For 2.6, using my current version requires James Simmons's fbdev-patch because of low-level fbdev-interface changes (like sysfs usage, etc). The whole framebuffer stuff in 2.6 is ancient. (Look at the file dates.)" Adrian suggested marking the FB_SIS option in 2.6 as "BROKEN" until it could be properly updated. Linus Torvalds also said:

Note that the fb stuff is ancient because it's basically not maintained as far as I'm concerned.

I occasionally get huge drops from James, and they invariably break stuff. Which means that I often decide (espcially when trying to stabilize things) that I just can't _afford_ to apply the fr*gging patches. Because by past experience applying one of the big "everything changes" patches tends to break more things that it fixes.

I'm sorry, but this i show it is. The fbcon people have been changing interfaces faster than they have been fixing bugs in the code. Together with the fact that most of the development seems to happen in outside trees, and nobody ever sends me fixes relative to the released tree, this makes for a pretty bad situation.

I really think that development should happen in the regular tree, or at least be synched up in reasonable chunks THAT DO NOT BREAK everything.

I realize that some fb developers seem to disagree with me, but the fact is, the way things are done now, fb will _always_ be broken. Most people for whom the standard kernel works will never test the fb development trees, so those trees will never get any amount of reasonable testing. As a result, they WILL be buggy, and synching with them WILL be painful as hell.

There is a d*mn good reason for why development should happen incrementally, and in the standard trees, and not in some outside tree. For one: testing. For another: figuring out when things break in a timely manner.

Some folks expressed the hope that the framebuffer patches would make it into the mainline tree, but no one addressed Linus' specific concerns.

7. Megaraid Driver 2.10.1 Released

9 Jan 2004 - 14 Jan 2004 (4 posts) Archive Link: "ANNOUNCE: megaraid driver version 2.10.1"

People: Atul MukkerMukker

Atul Mukker said:

The megaraid driver version 2.10.1 is released and can be downloaded from

Following other components are also available at this location:

  1. Patches for Red Hat and SuSE stock kernels
  2. Driver update disks for Red Hat and SuSE
  3. RPM packages to update drivers

A couple posts later, he also gave a link to a patch against the official 2.4 tree.

8. Linux 2.6.1-mm2 Released

10 Jan 2004 - 15 Jan 2004 (10 posts) Archive Link: "2.6.1-mm2"

Topics: FS: NFS, Kernel Release Announcement

People: Andrew Morton

Andrew Morton announced 2.6.1-mm2, saying:

9. Laptop-Mode Patch Version 7 Released For Kernel 2.6.1

10 Jan 2004 - 13 Jan 2004 (29 posts) Archive Link: "[PATCH] Laptop-mode v7 for linux 2.6.1"

Topics: Power Management: ACPI

People: Bart SamwelDax Kelson

Bart Samwel said:

I've created a new version of the laptop-mode patch, this time against linux 2.6.1. It can be found here:

It has no kernel code changes, only changes to the supporting documentation/scripts:

Especially Dax's addition should make it a lot more usable. I haven't been able to test this myself however, because I don't own a laptop. Dax probably does, so I'll trust him and assume that he has tested it. ;)

Dax Kelson confirmed that this patch seemed to be working on his laptop for the past few days. Various folks reported some problems, such as the disk not spinning down; and they tried to root out the bugs.

10. Status Of SiS964 SATA Support In 2.6

10 Jan 2004 - 11 Jan 2004 (3 posts) Archive Link: "SiS964 SerialATA RAID"

Topics: Serial ATA

People: Jeff GarzikLionel Bouton

Someone asked about the status of any SiS964 SATA drivers in the 2.6 tree, and Jeff Garzik said, "I'm not aware of any development in that direction, so far..." Lionel Bouton asked if there were docs or sample code available, but there was no reply on-list.

11. Experimental Net Driver Patch Reorganization

10 Jan 2004 - 12 Jan 2004 (3 posts) Archive Link: "[NETDEV] experimental net driver queue updated"

Topics: Networking, Version Control

People: Jeff Garzik

Jeff Garzik said:

The 250+ patch queue was getting way too big to manage, so using BK I split things up locally into a number of buckets. This allowed me to much more easily digest Al Viro's latest patch flood, as well as get things into much better shape for submission to upstream (as soon as the tree re-opens)... some changes were definitely more experimental than others, and won't go to Andrew/upstream until bugs and interface issues are fully sorted out.

This split-up allowed me to easily create broken-out sets of patches, which are available at the URL below.

Note the new "netdev" moniker too, that's not a typo.

Summary of new changes:

Summary of patchkit:


Full changelog:

Broken-out patches (broken out into "buckets" not changesets):

BK repo:

12. kexec Updated For 2.6.1

12 Jan 2004 (1 post) Archive Link: "[announce] kexec updated for 2.6.1"

Topics: Kexec

People: Randy Dunlap

Randy Dunlap said:

kexec is a linux-reboots-linux kernel patch. It currently applies only to x86/ia32.

Patch, scripts, userspace tools, etc., are available at

13. Adaptec Planning To Use MD For Their Own Software RAID Stack

12 Jan 2004 - 16 Jan 2004 (39 posts) Archive Link: "Proposed enhancements to MD"

Topics: Device Mapper, Disk Arrays: MD, Disk Arrays: RAID, Hot-Plugging

People: Scott LongMatt DomschArjan van de VenWakko WarnerNeil BrownIngo MolnarJeff GarzikJakob Oestergaard

Scott Long of Adaptec said:

Adaptec has been looking at the MD driver for a foundation for their Open-Source software RAID stack. This will help us provide full and open support for current and future Adaptec RAID products (as opposed to the limited support through closed drivers that we have now).

While MD is fairly functional and clean, there are a number of enhancements to it that we have been working on for a while and would like to push out to the community for review and integration. These include:

I'm going to push these changes out in phases in order to keep the risk and churn to a minimum. The attached patch is for the partition support. It was originally from Ingo Molnar, but has changed quite a bit due to the radical changes in the disk/block layer in 2.6. The 2.4 version works quite well, while the 2.6 version is fairly fresh. One problem that I have with it is that the created partitions show up in /proc/partitions after running fdisk, but not after a reboot.

Jakob Oestergaard was intrigued by Adaptec's plans, though he suspected that partition support for MD devices would not be likely to get into the 2.6 kernel in the near future. In fact, he thought the best solution would be to move MD into DM (Device Mapper). He proposed that Adaptec and IBM get someone to do that.

Elsewhere, Jeff Garzik also felt that Adaptec's focus on 2.4 was misplaced, as the 2.6 kernel was likely to be the Big Thing of the next few years. Matt Domsch replied, "Ideally in 2.6 one can use device mapper, but DM hasn't been incorporated into 2.4 stock, I know it's not in RHEL 3, and I don't believe it's included in SLES8. Can anyone share thoughts on if a DDF solution were built on top of DM, that DM could be included in 2.4 stock, RHEL3, or SLES8? Otherwise, Adaptec will be stuck with two different solutions anyhow, one for 2.4 (they're proposing enhancing MD), and DM for 2.6." Arjan van de Ven said, "Well it's either putting DM into 2.4 or forcing some sort of partitioned MD into 2.4. My strong preference would be DM in that cases since it's already in 2.6 and is actually designed for the multiple-superblock-formats case."

Close by, Scott explained why Adaptec had focused on 2.4 rather than 2.6; he said, " This work has actually been going on for a number of years in an on-and-off fashion. I'm just the latest person to pick it up, and I happened to pick it up right when the big transition to 2.6 happened."

Elsewhere, Arjan asked directly, why DM hadn't been used instead of MD, for the whole project. He said, "It really sounds like Device Mapper is the way to go to parse and use raid-like formats to the kernel, since it's designed to be independent of on disk formats, unlike MD." Wakko Warner replied, "As I've understood it, the configuration for DM is userspace and the kernel can't do any auto detection. This would be a "put off" for me to use as a root filesystem. Configurations like this (and lvm too last I looked at it) require an initrd or some other way of setting up the device. Unfortunately this means that there's configs in 2 locations (one not easily available, if using initrd. easily != mounting via loop!)"

Elsewhere, Neil Brown said he thought Adaptek's plan was great, though he saw no chance of anything getting into 2.4; and he and others hacked on it for awhile.

14. User-Mode Linux Updated To 2.6.0

12 Jan 2004 - 13 Jan 2004 (3 posts) Archive Link: "uml-patch-2.6.0"

Topics: User-Mode Linux, Version Control

People: Jeff Dike

Jeff Dike announced:

This patch updates UML to 2.6.0 and pulls in all the changes that have accumulated in my 2.4 tree.

The 2.6.0 UML patch is available at

BK users can pull my 2.5 repository from

For the other UML mirrors and other downloads, see

Other links of interest:

The UML project home page :
The UML Community site :

He replied to himself a little later, saying, "newer libcs won't boot on 2.6 UMLs until I get [gs]et_thread_area implemented. Older libcs are fine, as are new libcs on 2.4 UMLs."

15. UML Requirements For Freeing Dirty Pages

13 Jan 2004 - 16 Jan 2004 (11 posts) Archive Link: "[RFC] /dev/anon"

Topics: User-Mode Linux, Virtual Memory

People: Jeff DikeGeert UytterhoevenAndries BrouwerDavide LibenziNuno Silva

Jeff Dike said:

UML has a need to free dirty pages in the middle of a file (which is described in more detail below). The obvious way to do this, and one which has come up before, is a sys_punch system call for making a hole in the middle of a file. Since I need something like this now, and sys_punch is not immediately forthcoming, I implemented a special device which implements the semantics that UML needs.

/dev/anon acts just like anonymous memory, except for not being anonymous. It implements the memory freeing semantics by keeping track of how many times each page is mapped, and freeing pages when the map count goes to zero.

I did it by mashing the map counting into tmpfs. I've attached the patch (against 2.4.23) below. The main additions are

Comments on the implementation are welcome, as I'm not particularly proud of it, but nothing else came to mind quickly.

If this should be maintained out-of-tree, should I get an official minor for it anyway, or just unofficially use the first unused misc minor (10 in 2.4, 11 in 2.6)?

I'd also like opinions on whether this (or something like it) is sane enough to go into mainline, or whether I should just keep it as a out-of-tree patch until sys_punch shows up.

The immediate need for this would go away as soon as we got sys_punch.

On the other hand, a file backing anonymous memory seems superficially attractive because it can get rid of the vma->vm_file == NULL special cases scattered through the VM system. vm_file is expected to be the backing file for the data, which doesn't work so well for in-memory filesystems. tmpfs seems to know a lot about swapping pages out. It might be a good idea to resurrect the old swapfs idea and turn tmpfs into that. Then I guess vm_pgoff would become the equivalent of a swp_entry, which raises the question of what goes into a pte of a swapped-out page. Current convention says it becomes 0, which seems a bit wasteful. It's also not clear what vm_pgoff for an in-memory page would be. vmas like their data to be contiguous in the backing file, which suggests that there would be a swapfs file per process, with contiguous anonymous memory being contiguous in the swap file, if not on the actual device.

Regarding getting an official minor number, Geert Uytterhoeven remarked, "Apparently there's a hole in the list in 2.6.[01] (/dev/kmsg has 11), so you can use 10 for both 2.4 and 2.6." And Andries Brouwer confirmed, "Yes. 6 was /dev/core, added 0.98p3, removed 0.99p13X. 10 was reserved for /dev/aio, but when aio was implemented it was done differently. So 10 has never been used."

Elsewhere, Davide Libenzi suggested that sys_madvise(MADV_DONTNEED) might solve Jeff's whole problem. But Jeff replied, "MADV_DONTNEED is fine for anonymous memory, but it can't make a filesystem throw out data, which is what I need. If it did, then people wouldn't be agitating for sys_punch." Davide said, "What do you mean for throw out data? If you mean writing DONTNEED'ed dirty pages to the backed up file and release them to the page cache, it does. If you mean stop handling page faults inside the DONTNEED'ed region, it does not. If you mean zero-filling (ala ftruncate()) the DONTNEED'ed region, it obviously does not. I thought your goal was to release memory to the host, that's why I proposed sys_madvise(MADV_DONTNEED)." Nuno Silva gave a pointer to a document on the problem, and Jeff added that he really needed to release memory immediately as though it were clean; which MADV_DONTNEED wouldn't help with. Davide took a deeper look at the code, and found a comment that seemed to suggest that MADV_DONTNEED did indeed do what Jeff wanted, although Davide's own further tests showed the comment to be incorrect.

16. udev 013 Released

13 Jan 2004 - 15 Jan 2004 (12 posts) Archive Link: "[ANNOUNCE] udev 013 release"

Topics: FS: devfs, FS: sysfs, Hot-Plugging, Version Control

People: Greg KH

Greg KH announced:

I've released the 013 version of udev. It can be found at:

rpms built against Red Hat FC1 are available at:
with the source rpm at:

udev allows users to have a dynamic /dev and provides the ability to have persistent device names. It uses sysfs and /sbin/hotplug and runs entirely in userspace. It requires a 2.6 kernel with CONFIG_HOTPLUG enabled to run. Please see the udev FAQ for any questions about it:

For any udev vs devfs questions anyone might have, please see:

NOTE: The udev.rules file format has changed! If you have a modified config file it MUST be changed in order to work properly. Here's what needs to be done:

Also note the following changes in the way the udev.rules file is processed:

As a result of these changes, we can now create much more powerful rules by combining multiple key fields. Here's two new rules that show how you can do this:

# combined BUS, SYSFS and KERNEL
BUS="usb", KERNEL="video*", SYSFS_model="Creative Labs WebCam*", NAME="test/webcam%n"

# exec script only for the first ide drive (hda), all other will be skipped
BUS="ide", KERNEL="hda*", PROGRAM="/sbin/ide-devfs.sh_%k_%b_%n", RESULT="hd*", NAME="%1c", SYMLINK="%2c %3c"

Also, the result of the PROGRAM call is now cached accross multiple rules as long as a new PROGRAM key is not specified. As an example:

PROGRAM="/bin/echo_abc/index.html", RESULT="no_match", NAME="web-no-2"
KERNEL="video*", RESULT="123", NAME="web-no-3"
KERNEL="video*", RESULT="abc", NAME="web-yes"

The last rule would match properly.

Many thanks for these changes go to Kay Sievers. I really appreciate all of the development effort.

If anyone has any problems converting existing rules files, please see the example rules that are in the udev tarball, and feel free to ask questions on the linux-hotplug-devel mailing list.

Thanks again to everyone who has send me patches for this release, a full list of everyone, and their changes is below.

udev development is done in a BitKeeper repository located at:

Daily snapshots of udev from the BitKeeper tree can be found at:
If anyone ever wants a tarball of the current bk tree, just email me.

17. Linux 2.6.1-mm3 Released

14 Jan 2004 (12 posts) Archive Link: "2.6.1-mm3"

Topics: Disks: SCSI, Kernel Release Announcement

People: Andrew Morton

Andrew Morton announced 2.6.1-mm3, saying:

18. Linux 2.4.25-pre5 Released

15 Jan 2004 - 19 Jan 2004 (10 posts) Archive Link: "Linux 2.4.25-pre5"

Topics: Big Memory Support, SMP, USB, Virtual Memory

People: Marcelo Tosatti

Marcelo Tosatti announced 2.4.25-pre5, saying:

This version fixes the "memory filled with unfreeable inodes" problem which occurs on high memory machines in some workloads. That is the last big problem 2.4 VM had with highmem I believe.

It contains a few other important fixes:

Amongst others.

Please test it!

19. kgdb 2.0.4 Released

17 Jan 2004 (5 posts) Archive Link: "kgdb 2.0.4 with restructuring and fixes"

Topics: Spam

People: Amit S. KaleWilliam Lee Irwin IIIPavel MachekTom Rini

Amit S. Kale said, "kgdb 2.0.4 is available at" He said it included some restructuring by Tom Rini, "to allow architectures to provide different serial infos to the kgdb serial interface." Also, Amit said that Pavel Machek had done seme cleanups, as well as "changed calling convention from 0 on success, 1 on failure to 0 on success, -ERRNO on fail to be more consistent with rest of kernel" . Pavel had also "Made kgdb waiting for connection message KERN_CRIT," and added a change to "export kern_schedule only if CONFIG_KGDB_THREAD is defined" . William Lee Irwin III was very happy to see all of this, and asked, "Any chance you could splatter this out at a patch series to lkml for those of us so entrenched in pre-1994 conventions (such as myself) as to dislike chasing URL's from mailing list posts?" Amit gave a link to a tarball, adding apologetically, "I believe people will have me on their spammers list if I actually inflate this tarball and send as attachments. I sent 3 such postings this week!" Pavel replied, "Well, its 30K archive, that's pretty small. Sending it as patches has advantage that more people will actually see it and point errors..."

20. Status Of 2.0

17 Jan 2004 (2 posts) Archive Link: "linux-2.0.40-rc7"

People: David Weinehall

Seiichi Nakashima reported a compile-time bug with 2.0.40-rc7; and David Weinehall replied, "2.0.40-rc8 will be released early next week."







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.