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

Kernel Traffic #224 For 30�Jul�2003

By Zack Brown

If you like Kernel Traffic and want to send me a little money, click here:

Table Of Contents

Mailing List Stats For This Week

We looked at 3207 posts in 17182K.

There were 738 different contributors. 416 posted more than once. 205 posted last week too.

The top posters of the week were:

1. Better Support For Big-RAM Systems

8�Jul�2003�-�14�Jul�2003 (23 posts) Archive Link: "[announce, patch] 4G/4G split on x86, 64 GB RAM (and more) support"

Topics: Big Memory Support, Virtual Memory

People: Ingo Molnar,�Petr Vandrovec

Ingo Molnar said:

i'm pleased to announce the first public release of the "4GB/4GB VM split" patch, for the 2.5.74 Linux kernel:

The 4G/4G split feature is primarily intended for large-RAM x86 systems, which want to (or have to) get more kernel/user VM, at the expense of per-syscall TLB-flush overhead.

on x86, the total amount of virtual memory - as we all know - is limited to 4GB. Of this total 4GB VM, userspace uses 3GB (0x00000000-0xbfffffff), the kernel uses 1GB (0xc0000000-0xffffffff). This is VM scheme is called the 3/1 split. This split works perfecly fine up until 1 GB of RAM - and it works adequately well even after that, due to 'highmem', which moves various larger caches (and objects) into the high memory area.

But as the amount of RAM increases, the 3/1 split becomes a real bottleneck. Despite highmem being utilized by a number of large-size caches, one of the most crutial data structures, the mem_map[], is allocated out of the 1 GB kernel VM. With 32 GB of RAM the remaining 0.5 GB lowmem area is quite limited and only represents 1.5% of all RAM. Various common workloads exhaust the lowmem area and create artificial bottlenecks. With 64 GB RAM, the mem_map[] alone takes up nearly 1 GB of RAM, making the kernel unable to boot. Relocating the mem_map[] to highmem is very impractical, due to the deep integration of this central data structure into the whole kernel - the VM, lowlevel arch code, drivers, filesystems, etc.

with the 4G/4G patch, the kernel can be compiled in 4G/4G mode, in which case there's a full, separate 4GB VM for the kernel, and there are separate full (and per-process) 4GB VMs for user-space.

A typical /proc/PID/maps file of a process running on a 4G/4G kernel shows a full 4GB address-space:

 00e80000-00faf000 r-xp 00000000 03:01 175909     /lib/tls/
 00faf000-00fb2000 rw-p 0012f000 03:01 175909     /lib/tls/
 feffe000-ff000000 rwxp fffff000 00:00 0

the stack ends at 0xff000000 (4GB minus 16MB). The kernel has a 4GB lowmem area, of which 3.1 GB is still usable even with 64 GB of RAM:

 MemTotal:     66052020 kB
 MemFree:      65958260 kB
 HighTotal:    62914556 kB
 HighFree:     62853140 kB
 LowTotal:      3137464 kB
 LowFree:       3105120 kB

the amount of lowmem is still more than 3 times the amount of lowmem available to a 4GB system. It's more than 6 times the amount of lowmem a 32 GB system gets with the 3/1 split.

Performance impact of the 4G/4G feature:

There's a runtime cost with the 4G/4G patch: to implement separate address spaces for the kernel and userspace VM, the entry/exit code has to switch between the kernel pagetables and the user pagetables. This causes TLB flushes, which are quite expensive, not so much in terms of TLB misses (which are quite fast on Intel CPUs if they come from caches), but in terms of the direct TLB flushing cost (%cr3 manipulation) done on system-entry.

RAM limits:

in theory, the 4G/4G patch could provide a mem_map[] for 200 GB (!) of physical RAM on x86, while still having 1 GB of lowmem left. So it gives quite some legroom. While the right solution for lots of RAM is to use a proper 64-bit system, there's alot of existing x86 hardware, and x86 servers will still be sold in the next couple of years, so we ought to support them maximally.

The patch is orthogonal to wli's pgcl patch - both patches try to achieve the same, with different methods. I can very well imagine workloads where we want to have the combination of the two patches.

Implementational details:

the patch implements/touches a number of new lowlevel x86 infrastructures:

Whenever we do a syscall (or any other trap) from user-mode, the high-address trampoline code starts to run, with a high-address esp0. This code switches over to the kernel pagetable, then it switches the 'virtual kernel stack' to the regular (real) kernel stack. On syscall-exit it does it the other way around.

there are a few generic kernel changes as well:

but the generic-kernel impact of the patch is quite low.

the patch optimizes kernel<->kernel context switches and does not flush the TLB, also, IRQ entry only cases a TLB flush if a userspace pagetable is loaded.

the typical cost of 4G/4G on typical x86 servers is +3 usecs of syscall latency (this is in addition to the ~1 usec null syscall latency). Depending on the workload this can cause a typical measurable wall-clock overhead from 0% to 30%, for typical application workloads (DB workload, networking workload, etc.). Isolated microbenchmarks can show a bigger slowdown as well - due to the syscall latency increase.

i'd guess that the 4G/4G patch is not worth the overhead for systems with less than 16 GB of RAM (although exceptions might exist, for particularly lowmem-intensive/sensitive workloads). 32 GB RAM systems run into lowmem limitations quite frequently so the 4G/4G patch is quite recommended there, and for 64 GB and larger systems it's a must i think.

Status, future plans:

The patch is a work-in-progress snapshot - it still has a few TODOs and FIXMEs, but it compiles & works fine for me. Be careful with it nevertheless - it's an experimental patch which does very intrusive changes to the lowlevel x86 code.

There are a couple of performance enhancements ontop of this patch that i'll integrate into this patch in the next couple of days, but i first wanted to release the base patch.

In any case, enjoy the patch - and as usual, comments and suggestions are more than welcome.

A number of people liked the patch, and there was some technical discussion. Petr Vandrovec also remarked, "FYI, VMware's vmmon/vmnet I maintain for 2.5.x kernels at (currently .../vmware-any-any-update37.tar.gz) were updated to work correctly with 4G/4G kernel configuration."

2. Linux Test Project Update For July

10�Jul�2003 (1 post) Archive Link: "[ANNOUNCE] Linux Test Project July Release Announcement"

Topics: Bug Tracking, PCI, Power Management: ACPI, USB, Version Control

People: Robert Williamson

Robert Williamson announced:

The Linux Test Project test suite has been released. The latest version of the testsuite contains 2000+ tests for the Linux OS. Our web site also contains other information such as: test results, a Linux test tools matrix, an area for keeping up with fixes for known blocking problems in the 2.5 kernel releases, technical papers and HowTos on Linux testing, and a code coverage analysis tool.


We encourage the community to post results, patches or new tests on our mailing list and use the CVS bug tracking facility to report problems that you might encounter with the test suite.

3. Linux 2.5.75; Approaching 2.6; Andrew Morton Likely 2.6 Maintainer

10�Jul�2003�-�12�Jul�2003 (33 posts) Archive Link: "Linux 2.5.75"

People: Linus Torvalds,�Russell King

Linus Torvalds announced 2.5.75 and said:

Ok. This is it. We (Andrew and me) are going to start a "pre-2.6" series, where getting patches in is going to be a lot harder. This is the last 2.5.x kernel, so take note.

The probably most notable thing here is the anticipatory scheduler, which has been in -mm for a long time, and was the major piece that hadn't been merged.

Some architecture updates: cris has been updated for 2.5, ia64 and arm26 updates etc. And various random (smallish) things.

Russell King replied:

Well, only two words from me. Oh Shit.

The 2.5.70 ARM patch currently looks like this:

343 files changed, 45388 insertions(+), 7341 deletions(-)

and I don't see that this will be reducing in size now that 2.6 is around the corner.

I _know_ ARM stuff doesn't build and hasn't built in Linus' tree for a fair time now - there are some generic changes to support ARM modules needed in vmalloc.c which I just haven't had the time to sort out, and there's still the issue of whether /proc/kcore actually works or not, and now I see that the time stuff needs re-working for multiple ARM platforms yet again. (yes, all the other architectures got updated, except for ARM.)

Maybe I should just forget even attempting to merge upstream, like most of the ARM community doesn't.

Frustrated such an understatement.

Linus Torvalds replied, "Hey, this is already much later than it should have been, so it's not as if this is a huge surprise." He went on:

We can sort it out later. Obviously, clearly arm-specific patches (ie stuff in arch/arm and include/asm-arm) I wouldn't mind per se, but I'd rather hold back on even those just to make the patches and the changlogs not be mixed up with the "main bugfixes".

We've never had a first stable release that has all architectures up-to-date, and I'm not planning on changing that for 2.6.x. This is _not_ the time to try to make my tree build on arm (or other architectures either), considering that my tree hasn't been the main ARM tree for a long time.

Finally, to Russell's frustration, Linus said:

To be blunt, which part of "we want to release 2.6.x this year" came as a surprise to you?

That means that I'm not willing to hold stuff up any more. Stuff that hasn't followed the development tree doesn't magically just "get fixed".

Also, the only real point of a stable release is for distribution makers. That pretty much cuts the list of "needs to be supported" down to x86, ia64, x86-64 and possibly sparc/alpha.

So everything else is a bonus, but can equally well just play catch-up later. Embedded people tend to want to stay back anyway, which is obviously why they don't follow the development tree in the first place.

Russell said, "I can't think of any stock kernel which has been usable, let alone been compilable for ARM. Which, IMO, is a pretty sorry statement to make." To which Linus replied:

You see that as a sorry statement, but I don't think it's a failure. Why _should_ one tree have to try to make everybody happy? We want to try to make it easier to keep the couplings in place by striving for portable infrastructure etc, but we would only be hampered by a philosophy that says "everything has to work in tree X", since that just means that you can't afford to break things.

I'd much rather keep the freedom to break stuff, and have many separate trees that break _different_ things, and let them all co-exist in a friendly rivalry.

And my tree is just one tree in that forest.

So it's not a bug - it's a FEATURE!

4. Expected Changes From 2.4 To 2.6

11�Jul�2003�-�18�Jul�2003 (95 posts) Archive Link: "2.5 'what to expect'"

Topics: Access Control Lists, BSD: OpenBSD, Backward Compatibility, Big Memory Support, Big O Notation, Compression, Device Mapper, Disk Arrays: LVM, Disk Arrays: RAID, Disks: IDE, Disks: SCSI, Extended Attributes, FS: CIFS, FS: FAT, FS: InterMezzo, FS: JFS, FS: NFS, FS: NTFS, FS: ReiserFS, FS: UMSDOS, FS: VFAT, FS: XFS, FS: devfs, FS: ext2, FS: ext3, FS: sysfs, Forward Port, Framebuffer, Hot-Plugging, Hyperthreading, Ioctls, Kernel Build System, Microsoft, Modems, Networking, PCI, POSIX, Power Management: ACPI, Real-Time, SMP, Samba, Scheduler, Software Suspend, Sound: ALSA, Sound: OSS, USB, User-Mode Linux, Version Control, Virtual Memory, Web Servers

People: Dave Jones,�Oleg Drokin,�Paul Dickson,�Matthew Dharm,�Greg KH,�Pavel Machek,�Larry McVoy,�Davide Libenzi,�Jens Axboe,�Meelis Roos,�James Simmons,�Ingo Molnar,�Rik van Riel,�Rusty Russell,�Vojtech Pavlik,�Matt Domsch,�David Mosberger,�Adam Belay,�Ulrich Drepper,�Jeff Garzik,�Bert Hubert,�Steven Cole,�Alan Cox,�Peter Chubb,�Albert Cahalan,�James H. Cloos,�Keith Owens,�Robert Love,�Andrew Morton,�Zwane Mwaikambo

Dave Jones explained:

In preparation for the flood of testers as we approach 2.6pre, I thought I'd give this doc another airing to be sure that it isn't missing anything important.. (Plus I've been meaning to post an update for a while, and 42 sounded like a good number).

The post-halloween document. v0.42
(aka, 2.5 - what to expect)

Dave Jones <>

(Updated as of 2.5.75)

This document explains some of the new functionality to be found in the 2.5 Linux kernel, some pitfalls you may encounter, and also points out some new features which could really use testing. Note, that "contact" below also implies that you should also cc:

Latest version of this document can always be found at

Thanks to many [far too many to list] people for valuable feedback.

Note, that this document is somewhat x86-centric, but most features documented here affect all platforms anyway.

Spanish translation at:

Applying patches.

Known gotchas.

Certain known bugs are being reported over and over. Here are the workarounds.


(Things not expected to work just yet)

Deprecated features.


Kernel build system.

IO subsystem.

Enormous block size support.

POSIX ACLs & Extended attributes.

VM Changes.

Kernel preemption.

Process scheduler improvements.


Fast userspace mutexes (Futexes).


Davide Libenzi wrote an event based poll replacement that got included in 2.5. More info available at

Threading improvements.

Enhanced coredumping.

Input layer.

PnP layer.



Faster system calls.


Framebuffer layer.





Quota reworking.

The new quota system needs new tools. Supports 32 bit uids.

CD Recording.


Nanosecond stat:

The stat64() syscall got changed to return jiffies granularity. This allows make(1) to make better decisions on whether or not it needs to recompile a file. Not all filesystems may support such precision.


A number of additional filesystems have made their way into 2.5. Whilst these have had testing out of tree, the level of testing after merging is unparalleled. Be wary of trusting data to immature filesystems. A number of new features and improvements have also been made to the existing filesystems from 2.4.

Reports of stress testing with the various tools available would be beneficial.

Generic VFS changes.








In simple terms, the sysfs filesystem is a saner way for drivers to export their innards than /proc. This filesystem is always compiled in, and can be mounted just like another virtual filesystem. No userspace tools beyond cat and echo are needed.

mount -t sysfs none /sys

See Documentation/filesystems/sysfs.txt for more info.


IBM's JFS got merged during 2.5. (And backported to 2.4.20, but it was still a new feature here first. You can read more about JFS at


The SGI XFS filesystem has been merged, and has a number of userspace features. Users are encouraged to read for more information.

The various utilities for creating and manipulating XFS volumes can be found on SGI's ftp server:


Support utilities and documentation for the common internet file system (CIFS) can be found at


CVF (Compressed VFAT) support has been removed. This means you will no longer be able to access DriveSpace partitions.


Files in this filesystem are backed by large pages if the CPU supports them. See Documentation/vm/hugetlbpage.txt for more details.

Internal filesystems.

/proc/filesystems will contain several filesystems that are not mountable in userspace, but are used internally by the kernel to keep track of things. Amongst these filesystems are futexfs and eventpollfs


A system wide performance profiler has been included in 2.5. With this option compiled in, you'll get an oprofilefs filesystem which you can mount, that the userspace utilities talk to. You can find out more at


Improved BIOS table support.

Simple boot flag support.

The SBF specification is an x86 BIOS extension that allows improved system boot speeds. It does this by marking a CMOS field to say "I booted okay, skip extensive POST next reboot". Userspace tool is at More info on SBF is at

EDD Support.

Intel IPMI support.

x86 CPU detection.

Extra tainting.

Running certain AMD processors in SMP boxes is out of spec, and will taint the kernel with the 'S' flag. Running 2 Athlon XPs for example may seem to work fine, but may also introduce difficult to pin down bugs. In time it's likely this tainting will be extended to cover other out of spec cases.

Additionally, the new modules interface will taint the kernel if you try to 'force' a module to load with insmod -f.

Power management.

CPU frequency scaling.

Certain processors have the facility to scale their voltage/clockspeed. 2.5 introduces an interface to this feature, see Documentation/cpufreq for more information. This functionality also covers features like Intel's speedstep, and the Powernow! feature present in mobile AMD Athlons. In addition to x86 variants, this framework also supports various ARM CPUs. You can find a userspace daemon that monitors battery life and adjusts accordingly at:

Background polling of MCE.

The machine check handler has been extended so that it regularly polls for any problems on AMD Athlon, and Intel Pentium 4 systems. This may result in machine check exceptions occuring more frequently than they did in 2.4 on out of spec systems (Overclocking/inadequate cooling/underated PSU etc..).

LVM2 - DeviceMapper.

The LVM1 code got removed wholesale, and replaced with a much better designed 'device mapper'.

Debugging options.

During the stabilising period, it's likely that the debugging options in the kernel hacking menu will trigger quite a few problems. Please report any of these problems to rather than just disabling the relevant CONFIG_ options.

Merging of kksymoops means that the kernel will now spit out automatically decoded oopses (no more feeding them to ksymoops). For this reason, you should always enable the option in the kernel hacking menu labelled "Load all symbols for debugging/kksymoops".

Testing with CONFIG_PREEMPT will also increase the amount of debug code that gets enabled in the kernel. Kernel preemption gives us the ability to do a whole slew of debugging checks like sleeping with locks held, scheduling while atomic, exiting with locks held, etc.

Compiler issues.

Security concerns.

Several security issues solved in 2.4 may not yet be forward ported to 2.5. For this reason 2.5.x kernels should not be tested on untrusted systems. Testing known 2.4 exploits and reporting results is useful.





Oleg Drokin pointed out that ReiserFS supported inode attributes in 2.4.17 as well, and so couldn't really be considered a new feature in 2.5; but he added:

On the real new features list we have:

Paul Dickson also pointed out that the features Dave had marked "deprecated" were in fact already removed. As he put it, "Deprecated means "in the process of being phased out, but still usable"" .

Elsewhere, Matthew Dharm also pointed out for the little section on USB, "We may want to mention here that usb-storage has changed behavior. A device which is disconnected and then re-connected is not re-associated with the old /dev/ node. Also some performance enhancements."

Elsewhere, also regarding the USB section, Greg KH said:

The USB host controller drivers got renamed in 2.5. They are now:

uhci-hcd.o for UHCI USB host controllers
ohci-hcd.o for OHCI USB host controllers
ehci-hcd.o for EHCI (USB 2.0) host controllers

Elsewhere, James H. Cloos Jr. pointed out that in the "IO Subsystem" section, Dave had said that I/O elevators could be selected via 'elvtune', while in the deprecated section, Dave had said that 'elvtune' was deprecated, and that the elevators were actually tunable through a SysFS interface. Meelis Roos also made this connection elsewhere, and Dave and others tried to puzzle out whether 'elftune' would or would not be the preferred method.

Elsewhere regarding software suspend, Pavel Machek pointed out that it was not quite as badly off as Dave had described. Pavel said, "Actually it tends to work these days. No SMP, be carefull with PREEMPT, and no unusual hardware, and it should work."

Elsewhere, Alan Cox also had a number of comments about Dave's first post. Among them, he pointed out that the URL Dave had given for one of the BitKeeper changesets, was apparently incorrect. Larry McVoy replied, "I know, sorry. The version numbers in BK are not stable, they can't be. You have to use the underlying internal version number. If someone who knows can show me the output of 'bk changes -r<correct rev>' for that changeset I will figure out a way to have a URL that doesn't change and send it to Dave for that doc as well as post it there." Steven Cole said that looked correct.

5. Merging Software Suspend Patches; Aborting A Suspend-In-Progress

11�Jul�2003�-�15�Jul�2003 (53 posts) Archive Link: "Thoughts wanted on merging Software Suspend enhancements"

Topics: Big Memory Support, Compression, Power Management: ACPI, Software Suspend

People: Nigel Cunningham,�Pavel Machek,�Dmitry Torokhov,�Jamie Lokier,�Vojtech Pavlik

Nigel Cunningham asked:

As you may know, there has been a lot of work done on the 2.4 version of software suspend. This includes:

I'm wanting to get your thoughts on how we should go about merging it. I don't think these qualify as bug fixes, but current users (and I'm not excluding myself!) would certainly like to see the patch merged sooner rather than later. Would it be a good idea to seek to get Marcello and Andrew to take it into 2.4 and 2.6, and then aim for 2.[7|9]?

Pavel Machek objected to the idea of aborting a suspend operation by just pressing the ESC key. He said, "We don't want joe random user that is at the console to prevent suspend by just pressing Escape. Maybe magic key to do that would be acceptable..." Dmitry Torokhov replied that in most cases, the machine being suspended would be a laptop, and so there would only be one Joe User present. He said, "I myself would rather have an option to press ESC than remember what SysRq really maps to as by the time I would figure that out the laptop would already be suspended. IMHO, an option to use ESC, probably compile time option, is a good thing." But Pavel was against adding more compile options unless they were really necessary. He also said any keyboard solution would be ugly, including the magic sysrq, but that the magic sysrq would be useful enough to be acceptible. Jamie Lokier replied:

Can't you just use the Suspend button? :)

I'd be inclined to initiate suspend-to-disk when the laptop's lid is closed, or when I press the suspend button if ACPI would be so accomodating. After closing the lid, if I change my mind there's only two inputs I can do quickly: press the Suspend button, or open the lid. SysRq-Escape would take a couple of seconds longer due to needing to open the lid.

Of those, I'd be worried about the fragile lid switch occasionally bouncing as I moved the laptop, causing it to fail to suspend in my bag. The button is well protected.

Kent Borg said he wanted his laptop to keep running when the lid was closed, and Pavel said, "Of course, this *needs* to be configurable (== handled by userland). If you are using external keyboard/mouse you do not want your notebook open." But elsewhere he said that using the Suspend button would be acceptible in general. He said, "If it is the same button that would wake machine up when it finished suspend... I guess that makes sense."

Vojtech Pavlik suggested just having any keypress stop a suspend, but Nigel said this would make it too easy to accidentally interrupt the suspend. Elsewhere, Nigel said he still preferred using the Esc key. He said, "Having listened to the arguments, I'll make pressing Escape to cancel the suspend a feature which defaults to being disabled and can be enabled via a proc entry in 2.4. I won't add code to poll for ACPI (or APM) events :>" . Pavel suggested, "At least no new proc entry, please. Make it depend on sysrq_enabled and disable it completely if sysrq support is not compiled in." And Vojtech also suggested "making it a mappable function in the keymap, like reboot is for example. Both for initiating and stopping the suspend." There was a bit more discussion, but Nigel stood firm, and the thread petered out.

6. File-Time System Calls; Status Of ReiserFS

11�Jul�2003�-�15�Jul�2003 (8 posts) Archive Link: "utimes/futimes/lutimes syscalls"

Topics: FS: ReiserFS, FS: XFS

People: Ulrich Drepper,�Andrew Morton,�Nikita Danilov,�Tomas Szepe

Ulrich Drepper said:

With the introduction of the nanosecond fields in struct stat the utime() syscall is kind of obsolete. It's not possible anymore to restore the exact access/modification time of a file.

Unix defines the utimes() function for this. It is currently implementated in glibc on top of the utime() syscall which used to be OK but isn't anymore today. In addition some systems provide the futimes() and lutimes() functions which appropriate semantics.

The question: would a patch introducing these syscalls be accepted? If there are filesystems which store the sub-seconds on disk I think this is necessary since otherwise all kinds of programs (including archives) cannot be written correctly. If the sub-seconds only live in memory I still think it would be good to have the syscalls but it would not be that urgent.

Andrew Morton replied, "XFS (at least) stores nanoseconds on disk. So yes, I think we should make this change." And Nikita Danilov pointed out that ReiserFS also stored nanoseconds on disk.

Tomas Szepe asked, as a by-the-way, when ReiserFS would be ready at last, and Nikita replied:

Real soon now.

Latest benchmark results are available at the

we still have problems with delete performance, but in three to ten days reiser4 will be released to the public testing.

7. Linux 2.6.0-test1 Released

13�Jul�2003�-�18�Jul�2003 (16 posts) Archive Link: "Linux v2.6.0-test1"

People: Linus Torvalds

Linus Torvalds announced Linux v2.6.0-test1, and explained:

the naming should be familiar - it's the same deal as with 2.4.0.

One difference is that while 2.4.0 took about 7 months from the pre1 to the final release, I hope (and believe) that we have fewer issues facing us in the current 2.6.0. But very obviously there are going to be a few test-releases before the real thing.

The point of the test versions is to make more people realize that they need testing and get some straggling developers realizing that it's too late to worry about the next big feature. I'm hoping that Linux vendors will start offering the test kernels as installation alternatives, and do things like make upgrade internal machines, so that when the real 2.6.0 does happen, we're all set.

8. Status Of XBox Support

14�Jul�2003�-�15�Jul�2003 (12 posts) Archive Link: "[PATCH] XBox Gaming System subarchitecture."

Topics: Microsoft

People: Linus Torvalds,�Anders Gustafsson

Anders Gustafsson posted a patch adding XBox support to Linux, and Linus Torvalds replied:

Quite frankly, for Xbox support I want it to become a lot more commonly used before I actually put it into the standard kernel.

Why? Simply because for now it's still a fairly specialized thing, and as such I have to weigh the benefits of including it in the standard kernel against the negatives of just being a bit politically "hot potato".

Don't get me wrong: I think doing an Xbox port is fine. It's just that putting it in the standard tree is not likely a good idea. I can well imagine a number of Linux distributors who do not feel like they need the aggravation ;)

Anders replied:

Okey. Now I know, thanks. I assumed that it was either this or that it had to follow the standard procedure of posting the mach-patch(/patchset) a hundred times to lkml before it got accepted.

(And regarding the distros: They distributors could just rip that part out while doing all their patches ;). And I know that at least mandrake has a positive look on xbox-distro. And the mandrake devels were especially helpful in porting their installer to be compatible with the xbox.)

Just to make clear: The patch does nothing that involves anything with the copy-protection. Not even the hdd-unlock. It is aimed to those who replace the bios in the xbox with the clean microsoft-free cromwell-bios, which has the sole purpose of booting linux.

9. Linux 2.6 Feature Documentation By Joe Pranevich

14�Jul�2003�-�15�Jul�2003 (5 posts) Archive Link: "Wonderful World of Linux 2.6 - Linux 2.6 features document (first revision)"

Topics: Version Control

People: Joe Pranevich

Joe Pranevich said:

I've recently put together the first draft of a features document describing the changes in Linux 2.6. (I did similar documents for both Linux 2.2 and Linux 2.4.) It's based almost entirely on BitKeeper changelogs (with clarifying information pulled from the lists and the web), so there is a chance that I misunderstood something or that I missed something else entirely. Please give it a look over and if you see anything that needs a look-over, please let me know. As it stands now, I feel pretty good about how it turned out so I'm finally comfortable mailing what I have around. (There are still a couple areas that need expanding on, I think...)

As of right now, you can find the latest versions of the document available online.

Text version:

Tersely formatted HTML:

Several people praised Joe's work and recommended it, and offered corrections.

10. nfs-utils 1.0.4 Released

14�Jul�2003 (2 posts) Archive Link: "ANNOUNCE: nfs-utils 1.0.4"

Topics: FS: NFS

People: Neil F. Brown,�Steven Cole

Neil F. Brown announced:

This release of nfs-utils contains:

  1. Fix for a remotely exploitable buffer-overflow bug.
  2. assorted minor bug fixes
  3. Extensive changes to make use of new functionality in linux-2.6.0 nfsd

nfs-utils 1.0.4 can be downloaded from or http://www.{countrycode}

I consider this release to be a pre-release for 1.1.0 which I hope to release before linux-2.6.0-final. Bug reports are very welcome.

  1. A buffer-overflow bug was found by
    Janusz Niewiadomski
    iSEC Security Research

    It is trivially exploitable to effect a remote denial of service. More subtle exploits may be possible.

    I recommend that all users of nfs-utils either:

    1. upgrade to 1.0.4; or
    2. Get an update from their vendor (most vendors should have an update available).

    I also recommend that all NFS services be protected from the internet-at-large by a firewall where that is possible.

  2. See the change log in the source for details on bug fixes.
  3. In 2.4 and earlier kernels, the nfs server needed to know about any client that expected to be able to access files via NFS. This information would be given to the kernel by "mountd" when the client mounted the filesystem, or by "exportfs" at system startup. exportfs would take information about active clients from /var/lib/nfs/rmtab.

    This approach is quite fragile as it depends on rmtab being correct which is not always easy, particularly when trying to implement fail-over. Even when the system is working well, rmtab suffers from getting lots of old entries that never get removed.

    With 2.6 we have the option of having the kernel tell mountd when it gets a request from an unknown host, and mountd can give appropriate export information to the kernel. This removes the dependancy on rmtab and means that the kernel only needs to know about currently active clients.

    To enable this new functionality, you need to:
    mount -t nfsd nfsd /proc/fs/nfs

    before running exportfs or mountd.

    If you are using 2.6.0-testX and exporting files with NFS *please* test this out and let me know of any problems.

And Steven Cole posted a patch to Documentation/Changes to reflect this work.

11. RadeonFB Maintainership And Development Battles

14�Jul�2003�-�18�Jul�2003 (15 posts) Archive Link: "Re: radeonfb patch for 2.4.22..."

People: Ani Joshi,�Marcelo Tosatti,�Benjamin Herrenschmidt

Ani Joshi asked Marcelo Tosatti in private email, "Is there any particular reason why you decided to merge Ben H.'s radeonfb update instead of the one I sent you?" And Marcelo replied, "I merged his version because he sent me your update (0.1.8) plus his code (which are useful fixes he has been working on). It seems things are broken now due to a missing header, but he also sent me that. Do you have any objections to his fixes ?"

Ani replied that the patch he'd sent multiple times had included all of those fixes. He said that, as the driver maintainer, patches should be routed through him before going to Marcelo. It made no sense, he said, to allow everyone to patch the driver when they pleased, because that made it impossible to organize the work and make meaningful developments. Ani asked Marcelo to clarify his position on driver maintainership.

Marcelo replied that he hadn't realized Ben's code had been included in Ani's patch. He also said, "I received complains that you were not accepting patches from Ben. He needs that code in." And he added, "If you had accepted Ben's changes in the first place I wouldnt need to apply his patch." He also said that Benjamin Herrenschmidt was interested in taking over maintainership, and asked what Ani's and Ben's feelings would be about that.

Benjamin pointed out that Ani's patch did not contain all of his changes; and added, "I could take over if Ani wants to give up, though I would prefer a dedicated maintainer with more time to do the necessary rewrite of this driver in 2.6 and later, which I don't have time to do right now, however, I can maintain the existing code base if necessary."

Ani also replied to Marcelo, pointing to evidence that he had in fact accepted patches from Benjamin. He added, "Also, its hard to "accept patches" from people if you do NOT recieve any patches from them! Ben's style is to get the maintainers of drivers to go around and search for his personal tree and do their own diffs from that tree, instead of him sending a patch to the maintainer."

He added that Benjamin may have written more recent patches that were not included because they were so recent; and Ani also pointed out that anyone, including Marcelo, could also be accused of "not accepting patches"; and that it wasn't fair to judge solely on the basis of complaints.

Benjamin took umbrage at Ani's characterization of him as never submitting patches. He said he always posted his patches to the mailing list, and CCed Ani on all patch posts.

Marcelo said he'd revert Benjamin's patch and apply Ani's, and he asked Benjamin to send Ani a new patch that included all his additional fixes. He said he hoped this would make everyone happy.

12. Status Of Virtual Memory Documentation

15�Jul�2003 (2 posts) Archive Link: "VM docs and where they are going"

Topics: Virtual Memory

People: Mel Gorman

Mel Gorman said:

I made a small number of typo corrections and expanded the introduction chapter a small bit on the Linux VM docs on my site. The changes are small enough that if anyone has already printed it out, don't bother printing it again. They are still available from the usual places.

Main document

Code commentary

On the where it's going front from here, I'm happy to say I've now writing a book which will be published under the Bruce Peren's Open Book Series ( Some stuff that I'm working on for it include;

If all goes well, it'll be available before the end of this year or in early 2004 :-)

13. BitKeeper Snapshots For 2.6.0-test

18�Jul�2003 (3 posts) Archive Link: "2.6.0 BK snapshots"

Topics: Version Control

People: Jeff Garzik,�Martin Schlemmer

Martin Schlemmer asked if the 2.6.0-test series would have BitKeeper snapshots the way 2.5 did, and Jeff Garzik said:

I know, I know... ;-)

Suffixes ("-testN") break my snapshot process. Should be fixed sometime today...

Martin thanked him, and the thread ended.

14. Adeos M3 Released

18�Jul�2003 (1 post) Archive Link: "[ANNOUNCE] Adeos m3"

Topics: Microkernels: Adeos, Real-Time: RTAI, SMP

People: Philippe Gerum

Philippe Gerum said:

Adeos m3 for Linux is available at

This third milestone provides support for the following platforms:

Quite a lot of work has taken place since m2 was released a year ago, mostly aimed at improving stability and determinism in demanding real-time environments.

People seeking "real world" use of Adeos should have a look at the RTAI project:

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.