Table Of Contents
|1.||30 Dec 2003 - 11 Jan 2004||(172 posts)||Some Comparison Of devfs And udev|
|2.||5 Jan 2004 - 11 Jan 2004||(14 posts)||Linux 2.4.24 Released|
|3.||8 Jan 2004 - 13 Jan 2004||(6 posts)||ALSA 1.0.1 Released|
|4.||8 Jan 2004 - 11 Jan 2004||(7 posts)||Real-Time Interrupts|
|5.||8 Jan 2004 - 13 Jan 2004||(6 posts)||Linux 2.6.1 Released|
|6.||9 Jan 2004 - 15 Jan 2004||(37 posts)||Linus 2.6.1-mm1 Released; Framebuffer Development Problems|
|7.||9 Jan 2004 - 14 Jan 2004||(4 posts)||Megaraid Driver 2.10.1 Released|
|8.||10 Jan 2004 - 15 Jan 2004||(10 posts)||Linux 2.6.1-mm2 Released|
|9.||10 Jan 2004 - 13 Jan 2004||(29 posts)||Laptop-Mode Patch Version 7 Released For Kernel 2.6.1|
|10.||10 Jan 2004 - 11 Jan 2004||(3 posts)||Status Of SiS964 SATA Support In 2.6|
|11.||10 Jan 2004 - 12 Jan 2004||(3 posts)||Experimental Net Driver Patch Reorganization|
|12.||12 Jan 2004||(1 post)||kexec Updated For 2.6.1|
|13.||12 Jan 2004 - 16 Jan 2004||(39 posts)||Adaptec Planning To Use MD For Their Own Software RAID Stack|
|14.||12 Jan 2004 - 13 Jan 2004||(3 posts)||User-Mode Linux Updated To 2.6.0|
|15.||13 Jan 2004 - 16 Jan 2004||(11 posts)||UML Requirements For Freeing Dirty Pages|
|16.||13 Jan 2004 - 15 Jan 2004||(12 posts)||udev 013 Released|
|17.||14 Jan 2004||(12 posts)||Linux 2.6.1-mm3 Released|
|18.||15 Jan 2004 - 19 Jan 2004||(10 posts)||Linux 2.4.25-pre5 Released|
|19.||17 Jan 2004||(5 posts)||kgdb 2.0.4 Released|
|20.||17 Jan 2004||(2 posts)||Status Of 2.0|
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 KH, Prakash K. Cheemplavam
Greg KH said:
(This text can be found at kernel.org/pub/linux/utils/kernel/hotplug/udev_vs_devfs (http://www.kernel.org/pub/linux/utils/kernel/hotplug/udev_vs_devfs) 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,
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 kernel.org 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...
So, how does devfs stack up to the above problems and constraints:
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:
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:
Prevent users from ever worrying about major/minor numbers
And here you were, not knowing you ever needed to worry about major/minor numbers in the first place, right? Ah, I see you haven't plugged in 2 USB printers and tried to figure out which printer was which /dev entry? Or plugged in 4000 SCSI disks and tried to figure out how to access that 3642nd disk and what it was called in /dev. Or plugged in a USB camera and a USB flash drive and then tried to download the pictures off of the flash drive by accident?
As the above scenarios show, both desktop users and big iron users both need to not worry about which device is assigned to what major/minor device.
udev doesn't care what major/minor number is assigned to a device. It merely takes the numbers that the kernel says it assigned to the device and creates a device node based on it, which the user can then use (if you don't understand the whole major/minor to device node issue, or even what a device node is, trust me, you don't really want to, go install udev and don't worry about it...) As stated above, if the kernel decides to start randomly assigning major numbers to all devices, then udev will still work just fine.
Provide a persistent device naming solution:
Lots of people want to assign a specific name that they can talk to a device to, no matter where it is in the system, or what order they plugged the device in. USB printers, SCSI disks, PCI sound cards, Firewire disks, USB mice, and lots of other devices all need to be assigned a name in a consistent manner (udev doesn't handle network devices, naming them is already a solved solution, using nameif). udev allows users to create simple rules to describe what device to name. If users want to call a program running a large database half-way around the world, asking it what to name this device, it can. We don't put the naming database into the kernel (like other Unix variants have), everything is in userspace, and easily accessible. You can even run a perl script to name your device if you are that crazy...
For more information on how to create udev rules to name devices, please see the udev man page, and look at the example udev rules that ship with the tarball.
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 Kysela, Joshua 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 http://linux-sound.bkbits.net/linux-sound
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"
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 Morton, Prakash K. Cheemplavam, Thomas Winischhofer, Linus Torvalds, Adrian Bunk, James Simmons
Andrew Morton announced 2.6.1-mm1, saying:
Added support for kgdb on the x86_64 platform. You'll need a couple of patches to gdb-6.0 itself to use it properly. They may be found at
A large s390 update. Various device drivers and IO layer changes there.
Note that the 's390' patches actually include significant core MM changes in the area of pte writeback/invalidate, rmap tweaks, etc. Relevant patches are:
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 Mukker, Mukker
Atul Mukker said:
The megaraid driver version 2.10.1 is released and can be downloaded from ftp://ftp.lsil.com/pub/linux-megaraid/drivers/version-2.10.1/
Following other components are also available at this location:
A couple posts later, he also gave a link to a patch against the official 2.4 tree (ftp://ftp.lsil.com/pub/linux-megaraid/drivers/version-2.10.1/megaraid-linux-2.4.24-megaraid-2.10.1.patch) .
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 Samwel, Dax 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 Garzik, Lionel 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:
Broken-out patches (broken out into "buckets" not changesets):
12. kexec Updated For 2.6.1
12 Jan 2004 (1 post) Archive Link: "[announce] kexec updated for 2.6.1"
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 Long, Matt Domsch, Arjan van de Ven, Wakko Warner, Neil Brown, Ingo Molnar, Jeff Garzik, Jakob 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:
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 Dike, Geert Uytterhoeven, Andries Brouwer, Davide Libenzi, Nuno 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. (/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 (http://user-mode-linux.sourceforge.net/devanon.html) , 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:
An I/O scheduler tuning patch. This is the 114th patch against the anticipatory scheduler and we're nearly finished, honest. Now would be a good time for people to run the appropriate benchmarks.
We're still not as good as deadline on some seeky loads, and deep SCSI TCQ still hurts a lot. But it is looking good on average.
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:
Please test it!
19. kgdb 2.0.4 Released
17 Jan 2004 (5 posts) Archive Link: "kgdb 2.0.4 with restructuring and fixes"
People: Amit S. Kale, William Lee Irwin III, Pavel Machek, Tom Rini
Amit S. Kale said, "kgdb 2.0.4 is available at http://kgdb.sourceforge.net" 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 (http://kgdb.sourceforge.net/kgdb-2/linux-2.6.1-kgdb-2.0.4.tar.bz2) , 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 kernel.org. All pages on this site are copyright their original authors, and distributed under the terms of the GNU General Public License version 2.0.