Kernel Traffic #265 For 30 Jun 2004

By Zack Brown

Table Of Contents

Mailing List Stats For This Week

We looked at 2035 posts in 10603K.

There were 497 different contributors. 245 posted more than once. 248 posted last week too.

The top posters of the week were:

1. Some Explanation Of Disk Geometry Handling In 2.4 And 2.6

30 May 2004 - 3 Jun 2004 (33 posts) Archive Link: "2.6.x partition breakage and dual booting"

Topics: Disk Arrays: RAID, Disks: IDE, Disks: SCSI, FS: FAT, Ioctls

People: Jeff GarzikAndries Brouwer

Jeff Garzik said:

So it seems that the 2.6.x geometry code breaks dual booting, since Windows wants "sane" CHS values. See the thread on slashdot, or

Although Fedora Core is current taking grief for this, it's really a 2.6.x kernel problem AFAICT.

Has anybody taken the time to hunt down the csets that cause this massive partition table breakage? If so, it will save me some time tracking this down.

Andries Brouwer said that the slashdot thread related only to a user-space problem, and that the fdisk program maintained by Andries worked perfectly. He said, "I can tell you in great detail all about disk geometry, and the 2.4 situation and the 2.6 situation." Jeff asked for this great detail, and Andries replied:

I already wrote several many-page texts on this stuff. See, e.g.,

Attempt at a brief summary:

  1. Hardware:

    In the ancient past a disk (MFM or RLL) had a geometry describing how many sectors per track, how many tracks (cylinders), and how many heads the thing had.

    With the advent of IDE it no longer was true that a disk has a well-determined geometry: the ATA command INITIALIZE DRIVE PARAMETERS will tell the disk what geometry it is supposed to have today.

    An IDE disk can be accessed in CHS and in LBA mode, and the geometry specified, or read via the ATA IDENTIFY command, defines the meaning of a CHS command. With LBA access no geometry plays a role.

    SCSI disks never had this geometry nonsense.

    Linux uses LBA and does not need to concern itself with geometry.

  2. DOS / Windows:

    The DOS disk interface used CHS. If the disk uses LBA the driver has to convert CHS to LBA and hence needs a geometry (at least H, S).

    Because DOS (BIOS INT 13) had 10 bits for C, and 6- bits for S, while ATA uses 4 bits for H, this scheme could address only somewhat less than 2^20 sectors. The 528 MB limit.

    All kinds of translation schemes were invented to give the BIOS interface a geometry different from that used at the ATA interface. The user chooses a translation scheme in the BIOS setup. The geometry is now unrelated to the disk, but is known to the BIOS.

    Various BIOS calls exist that report on various versions of the geometry.

  3. Partition tables:

    A DOS-type partition table (see, e.g., gives the location of a partition in two ways. One is the way used by Linux (the starting sector and length, both given in 32 bits). The other, used by DOS, given CHS for the first and for the last sector (both in 24 bits).

    Even when nobody cares about geometry any longer, is it still necessary to fill these CHS fields.

    If the filesystem living in the partition is a FAT filesystem, then the boot sector of the FAT filesystem again gives information on the size of the partition.

  4. Linux:

    There is an ioctl HDIO_GETGEO that returns the geometry of a disk and the starting sector (offset) of a partition. There is an ioctl BLKGETSIZE that returns the size (in 512-byte sectors) of a block device in 32 bits. There is an ioctl BLKGETSIZE64 that returns the size (in bytes) of a block device in 64 bits.

    Clearly, BLKGETSIZE is obsolescent - it should be replaced by BLKGETSIZE64 everywhere. 2^41 B is 2 TB, and some RAIDs are larger.

    The HDIO_GETGEO ioctl gives heads, sectors and cylinders - fields of 1, 1, 2 bytes. On the one hand that is reasonable - no interface exists that can use more than 16 bits for the number of cylinders. On the other hand there is still some broken software that computes the size of a disk as C*H*S, and obtains C, H, S by HDIO_GETGEO. Of course this is broken, and introducing a new ioctl is no good - such software must be fixed to use BLKGETSIZE64.

  5. Geometry use under Linux:

    Roughly speaking geometry was needed under Linux for two purposes: LILO (and similar bootloaders) and *fdisk. Of course, also programs that tried to emulate aspects of DOS/Windows are interested in a geometry.

    The LILO aspect has disappeared - with options like linear, or lba32, lilo uses linear sector numbers at install time, and converts them to CHS, when needed, at boot time.

    The fdisk aspect has also disappeared - after this geometry business had become infinitely complicated, nobody any longer tried to understand geometry, but just inferred from the partition table what geometry was used by the program that last wrote it.

    How did the kernel find a geometry? Mainly in three ways: (i) from boot parameters, (ii) by looking at the partition table, (iii) by asking the BIOS at boot time, before switching to protected mode.

    Information (i) - explicit specification - and (ii) - partition table - is also available to user space, no kernel needed. Remains the question whether (iii) is a good idea.

    It didnt always work, but often it worked. (And only on i386 of course.) Examples of failure: The code we had only asked the BIOS for info on the first two disks. An often-posed question was: I have two identical disks, how come they get different geometries? Also, the code we had failed when the system had SCSI disks. Also, the code we had assumed that the first two BIOS disks were hda and hdb. But there is no reason why that would be the case. For example, many people kept their large disks out of the BIOS since it would crash upon seeing big disks.

    So, this (iii) was a bit messy stuff with many problems, but OK for most people.

  6. The present

    Linux no longer makes any attempt to invent a geometry. If someone needs a geometry, he is responsible himself for choosing one of the many concepts of geometry, and determining a value. What most software does is looking at the partition table, and that works.

    Maybe parted has not yet been updated to do this, that is why I conjectured that Fedora problems might be due to the use of parted.

    Was this a loss? I don't think so, but there is at least one use of the old situation that fails today: the installation of Windows systems from Linux media on a completely blank disk.

2. Linux 2.6.7-rc2-mm1 Released; Linux 2.7 May Require GCC Version Greater Than 2.x

1 Jun 2004 - 6 Jun 2004 (69 posts) Archive Link: "2.6.7-rc2-mm1"

Topics: FS: NFS, Kernel Release Announcement, Networking, Profiling

People: Andrew MortonAlexander GranDavid S. MillerLinus TorvaldsAdrian Bunk

Andrew Morton announced Linux 2.6.7-rc2-mm1, saying:

Alexander Gran remarked, "I can neither enter nor activate the gigabit ethernet driver section in menuconfig." Andrew replied that he had no problem with that; and David S. Miller said, "It seems you have to enable the 10/100 section in order to get to the gigabit section. This is the case in the standard tree too, nothing in -mm changed this." Alexander tried and confirmed this, saying, "Ahh, all right. Than the bug was introduced with 2.6.7-rc2."

Elsewhere, Adrian Bunk reported seeing a lot of warnings about dereferencing void pointers during compilation, when compiling with GCC 2.95; Linus Torvalds replied:

Yes. Apparently gcc-2.95 doesn't like to dereference a "void *" even just inside of a "__typeof__". Which is a bit silly, since the result is a perfectly valid _type_. It's obviously been fixed since, so I never saw this.

(Aside - with anon unions also not working in older gcc's, I suspect we'll start requiring gcc-3+ in the 2.7.x timeframe. I know it's a lot slower, but apparently at least it now is starting to generate comparable code again).

Anyway, the easiest work-around would be to just avoid derefencing the pointer, but then you have to add strange modifiers (both "const" and "volatile" at the same time) to make sure that gcc won't complain about the assignment dropping any modifiers.

So the fix I'm going to check in is to just make "__chk_user_ptr()" be something that gcc never even sees, which allows us to simplify it for the sparse case too.

In other words, this should work for even old versions of gcc.. Just to be anal, you should probably test on gcc-2.95 ;)

Adrian tried Linus' fix and confirmed that it worked with GCC 2.95.

3. Status Of SysFS Maintainership

1 Jun 2004 - 4 Jun 2004 (2 posts) Archive Link: "Sysfs maintainer"

Topics: FS: sysfs, MAINTAINERS File

People: Greg KH

Christian Gmeiner was trying to contact the SysFS maintainer, but couldn't seem to find any information on who that person might be; Greg KH replied, "I'm the de-facto sysfs and driver core maintainer these days, I guess I should add that to the MAINTAINERS file eventually..."

4. 'NX' Security Features Coming To 2.6

2 Jun 2004 - 8 Jun 2004 (66 posts) Archive Link: "[announce] [patch] NX (No eXecute) support for x86, 2.6.7-rc2-bk2"

Topics: Executable File Format, Microsoft, Security, Spam, Virtual Memory

People: Ingo MolnarLinus TorvaldsDoug McNaughtJakub JelinekBrian GerstChristoph HellwigWilliam Lee Irwin IIIAndi KleenAndy LutomirskiArjan van de VenGerhard MackJun NakajimaRusty Russell

Ingo Molnar said on behalf of Red Hat:

we'd like to announce the availability of the following kernel patch:

which makes use of the 'NX' x86 feature pioneered in AMD64 CPUs and for which support has also been announced by Intel. (other x86 CPU vendors, Transmeta and VIA announced support as well. Windows support for NX has also been announced by Microsoft, for their next service pack.) The NX feature is also being marketed as 'Enhanced Virus Protection'. This patch makes sure Linux has full support for this hardware feature on x86 too.

What does this patch do? The pagetable format of current x86 CPUs does not have an 'execute' bit. This means that even if an application maps a memory area without PROT_EXEC, the CPU will still allow code to be executed in this memory. This property is often abused by exploits when they manage to inject hostile code into this memory, for example via a buffer overflow.

The NX feature changes this and adds a 'dont execute' bit to the PAE pagetable format. But since the flag defaults to zero (for compatibility reasons), all pages are executable by default and the kernel has to be taught to make use of this bit.

If the NX feature is supported by the CPU then the patched kernel turns on NX and it will enforce userspace executability constraints such as a no-exec stack and no-exec mmap and data areas. This means less chance for stack overflows and buffer-overflows to cause exploits.

furthermore, the patch also implements 'NX protection' for kernelspace code: only the kernel code and modules are executable - so even kernel-space overflows are harder (in some cases, impossible) to exploit. Here is how kernel code that tries to execute off the stack is stopped:

 kernel tried to access NX-protected page - exploit attempt? (uid: 500)
 Unable to handle kernel paging request at virtual address f78d0f40
  printing eip:

The patch is based on a prototype NX patch written for 2.4 by Intel - special thanks go to Suresh Siddha and Jun Nakajima @ Intel. The existing NX support in the 64-bit x86_64 kernels has been written by Andi Kleen and this patch is modeled after his code.

Arjan van de Ven has also provided lots of feedback and he has integrated the patch into the Fedora Core 2 kernel. Test rpms are available for download at:

the kernel-2.6.6-1.411 rpms have the NX patch applied.

here's a quickstart to recompile the vanilla kernel from source with the NX patch:

There were a lot of technical suggestions and comments from folks like Christoph Hellwig, Andi Kleen, Rusty Russell, and Gerhard Mack. Also, Linus Torvalds asked:

Just out of interest - how many legacy apps are broken by this? I assume it's a non-zero number, but wouldn't mind to be happily surprised.

And do we have some way of on a per-process basis say "avoid NX because this old version of Oracle/flash/whatever-binary-thing doesn't run with it"?

In answer to the first question, Ingo and Arjan van de Ven (also from Red Hat) confirmed that the amount of legacy breakage was in fact zero. Ingo also explained that just in case, any breakage from this would be less than other breakage already introduced by Red Hat. He put it, "in the full install of FC1 and FC2 the number is zero - and Fedora has exec-shield which does a couple of things more: it makes the heap non-executable as well [this broke X], it randomizes the address-space layout and has a 4:4 VM [which broke the Sun JVM]." Doug McNaught added, close by, "Lisp systems like CMUCL and SBCL (plus commercial Lisps) had problems with FC1 due to execshield. They tend to do things like compile code on the fly to heap memory and expect to be able to run it." And Jakub Jelinek (also from Red Hat) replied, "They will still work, as long as you don't recompile them with recent toolchain. When you recompile them, they either needs to be taught to DTRT (i.e. use mmap with PROT_EXEC for executable stuff), or can be linked with -Wl,-z,execstack to mark them as needing executable stack. prelink package also contains execstack(8) utility which can be used on already linked binaries/shared libraries."

To Linus' second question, about the possibility of per-process avoidance of NX for compatibility reasons, Ingo explained:

we have three mechanisms for this in Fedora:

  1. the PT_GNU_STACK flag itself - you can turn executability on/off compile-time or even after the fact via the execstack(8) utility Jakub wrote. This only affects the stack's executability - if an application assumes a non-PROT_EXEC mmap() can be executed it might still break with NX - but based on experience with Fedora Core i'd say there's almost no such application.

    this method works in 2.6 too, since it supports PT_GNU_STACK. gcc's PT_GNU_STACK mechanism is very conservative - e.g. if an application does an asm() then gcc assumes that it might rely on stack executability and emits the X flag. [applications can then turn this off in the source if stack executability is not required.] Likewise, if gcc emits trampolines then the X flag is emitted too. (glibc knows about PT_GNU_STACK all across - so e.g. if a nonexec stack application dlopen()s a library that needs stack executability then glibc makes the stack executable on the fly via PROT_GROWSDOWN/GROWSUP.)

  2. via a runtime method: via the i386 personality. So an application can trigger the 'legacy' Linux VM layout by e.g doing 'i386 java ./test.class'.

    this is a hack in Fedora - we wanted to have a finegrained runtime mechanism just in case. But it would be nice to have this upstream too - e.g. via a PERSONALITY_3G?

  3. via a kernel boot parameter (exec-shield=0)

    with the NX patch this becomes noexec=off [the same flag works on x86_64 too]. This method is the most inflexible one, and is a last-resort thing. (Fedora also has a runtime global switch to turn off the VM layout changes.)

here's a list of applications that we had to fix/work around in Fedora when the VM layout changed:

most of the breakages were unclean x86-only code that would have broken if ported over to 64-bit anyway.

old, legacy applications dont have the PT_GNU_STACK flag so they all work fine.

Regarding Wine's breakage when the Virtual Memory Subsystem changed, Brian Gerst disagreed with Ingo's explanation, and remarked, "Wine breaks because of the part of exec-shield that relocates shared libs to low addresses, where the (stripped) Windows binaries expect to be loaded at. NX stack doesn't affect it." Ingo accepted this, adding, "I think Wine could get around this by creating a dummy ELF section in the Wine binary that covers the first 1GB or so. Wine could still use ordinary dynamic libraries - those would go above that 1GB. Then once Wine has loaded up it can munmap() that first 1GB. (this would not work if Wine has to dlopen() new libraries after this phase - does that happen?)" But Christoph Hellwig suggested, "Why can't wine just implement it's own binfmt_pecoff? Sounds like the much simpler solutuion." And William Lee Irwin III said, "I'd be in favor of this also. An executable format with wide enough usage is worth adding kernel support for loading it."

Ingo replied also to his own long post, dealing with his item 2 above, the runtime method of triggering the legacy Linux VM subsystem. He said:

i've attached a patch that provides a cleaner solution. It does 3 changes:

(the patch also adds a break to the elf_ex.e_phnum loop - there can only be one STACK header in the binary and once we found it we should not iterate through the remaining program headers (if any).)

we didnt want to add a non-standard personality flag to Fedora so we abused PER_LINUX32 as the compatibility flag - but this only works on x86. With the ADDR_SPACE_EXECUTABLE flag there would be a standard method to fall back to 'legacy' executability assumptions Linux applications might make.

Andi replied to the third item in the list above, regarding clearing the 'personality' when executing a setuid binary. He said, "This means I cannot easily force an i386 uname or 3GB address space on suid programs anymore on x86-64. While in theory it could be a small security problem I think the utility is much greater. It's hard to see how setting NX could cause a security hole. The program may crash, but it is unlikely to be exploitable." Andy Lutomirski replied:

The whole point of NX, though, is that it prevents certain classes of exploits. If a setuid binary is vulnerable to one of these, then Ingo's patch "fixes" it. Your approach breaks that.

I don't like Ingo's fix either, though. At least it should check CAP_PTRACE or some such. A better fix would be for LSM to pass down a flag indicating a change of security context. I'll throw that in to my caps/apply_creds cleanup, in case that ever gets applied.

Andi thought it would be overkill to require an LSM module, but he agreed that Andy had a good point, although Andi also objected, "that only applies to the NX personality bit. For the uname emulation it is not an issue. So maybe the dropping on exec should only zero a few selected personality bits, but not all." This made sense to Andy; and close by, Ingo said, "ok, how about the attached patch then? There's a PERS_DROP_ON_SUID mask that we drop upon setuid - all the other personality bits get inherited." Andy replied, "This is wrong on SELinux (and presumably with other LSMs). It also does unexpected things if you fail to exec a setuid executable." He posted his own patch, and Linus Torvalds came in with:

Let's not do this at all.

Anything that changes subtle behaviour at suid-execute time is just wrong. Imagine an app that has been tested in normal use, and then has a subtle bug when executed set-uid, simply because the address space layout changes. Or something that mysteriously works when you're root, but not when you're anything else. Ouch.

I think we should just look at the executable itself, not whether it is suid. If the executable says it is "NX-approved", then it's NX-approved. End of story - just try to make sure that as many executables as possible get compiled with the newer compiler suite that enables it.

Add a tool to let people turn on/off the NX bit on an executable if it turns out the executable can't work with it (let's say it was compiled and tested on a CPU without NX support), and everybody should be happy. You can have a trivial script that turns on the NX bit on all the legacy apps too, and then if testing shows iot wasn't a good idea, you can turn it off again on a per-executable basis.

Ingo did a bunch more work, posting patches; and Arjan also remarked, "the prelink rpm on Fedora has such a tool" [to flip the NX bit on an executable] "already fwiw. (it's part of prelink because the elf manipulations needed are quite similar to the ones prelink does so infrastructure is shared)" Linus replied:

Just for fun, can somebody that has the required hardware just test old apps with NX turned on?

I know we used to put the signal handler trampoline on the stack, but these days that should all be handled with the magic executable syscall page, so _normally_ I don't think an old application should even really care.

In fact, it would be interesting to just hear somebody running an older distribution with a new CPU and a new kernel, and see just how many programs need to be marked non-NX in "normal running".

Arjan replied, "I know that in a FC1 full install there are less than 5 binaries that don't run with NX. (one uses nested functions in C and passes function pointers to the inner function around which causes gcc to emit a stack trampoline, and gcc then marks the binary as non-NX, the others have asm in them that we didn't fix in time to be properly marked)." And Linus said:

If things are really that good, why are we even worrying about this?

It sounds like we should just have NX on by default even for executables that don't have any NX info records, and have some way of marking the (very few) executables that don't want it. Maybe have the NX fault print a warning when it happens for an executable that defaulted to NX on.

I think most people have seen the security disaster that causes most of the emails on the net to be spam. So this should be _trivial_ to explain to people when they complain about default behaviour breaking their strange legacy app. Especially if there's a trivial tool to add an elf section to make it work again.

So instead of having complex things to try to turn NX on for suid, we should aim to turn ot on as widely as possible, _even_if_ that means that people who upgrade hardware might have to do some trivial MIS stuff.

Make a kernel bootup option to default to legacy mode if somebody literally has trouble booting and fixing their thing due to "init" or similar being one of the problematic cases. Together with a printk() that says which executable triggered, it should be trivial to clean up a system.

5. exec-shield Patch Updated For 2.6.7-rc2-bk2

2 Jun 2004 - 4 Jun 2004 (4 posts) Archive Link: "[patch] exec-shield patch for 2.6.7-rc2-bk2, integrated with NX"

Topics: Big Memory Support

People: Ingo MolnarChristoph HellwigJoe Korty

Ingo Molnar said:

Here's the latest exec-shield patch for 2.6.7-rc2-bk2, integrated with the 'NX' feature (see the announcement from earlier today):

you first have to apply the NX patch, which can be found at:

prebuild kernel RPMs for Fedora Core 2, with this latest version of exec-shield, are available at:

(kernel-2.6.6-1.411 has this latest, NX-aware exec-shield.)

if the CPU supports NX (and the kernel has been compiled with CONFIG_HIGHMEM64G) then exec-shield will use NX to provide page-level finegrained control over execution. On legacy CPUs that dont support NX the segment-limit method is used to control execution (in a coarser way). In the NX case the segment-limit is turned off altogether.

e.g. on an Athlon64 box the boot message looks:

NX (Execute Disable) protection: active

on a CPU without NX the boot message is:

NX (Execute Disable) protection: not present!
Using x86 segment limits to approximate NX protection

note: the NX patch will also protect against kernel-space code injection.

all the other components of exec-shield are identical between NX and non-NX: the brk area is non-executable, libraries and PIE binaries are moved into the ascii-shield as much as possible, and all aspects of the address space are randomized.

Christoph Hellwig thought the patch was too big and included more stuff than some folks would want. He asked, "Any chance to split this up a bit? Having the pure non-exec stack (and maybe heap) would be really nice while the randomization feature are a litte bit too much security by obscurity for my taste." Joe Korty disagreed, "It's no more security by obscurity than keeping your key secret is security by obscurity. (One can think of the randomization as a white-noise key)." Nevertheless, Ingo posted a new patch with the randomization code removed. But he added, "but i still think randomization is useful as a last-resort barrier, against worm-alike mass attacks. There's a huge difference between a 1-packet infection and a 2-hour brute-force search over broadband, in terms of the 'economy' of worms."

6. Linux 2.4.27-pre5 Released

2 Jun 2004 - 6 Jun 2004 (9 posts) Archive Link: "Linux 2.4.27-pre5"

People: Marcelo Tosatti

Marcelo Tosatti announced Linux 2.4.27-pre5, saying, "This time we have merges from Jeff's -netdrivers tree, David's -net tree, including a fix for compilation error without CONFIG_SCTP set, SPARC64 update, i810_audio fixes, amongst others."

7. Linux Test Project Updated

3 Jun 2004 (1 post) Archive Link: "[ANNOUNCE] JUne LTP release now available"

People: Marty Ridgeway

Marty Ridgeway announced the Linux Test Project version 20040603, saying:


8. Some Developer Disconnect Over ia64 Maintainership

4 Jun 2004 (2 posts) Archive Link: "[PATCH] ia64 MAINTAINERS update"

Topics: MAINTAINERS File, Version Control

People: Grant GrundlerJesse Barnes

Jesse Barnes noticed that the ia64 web site and mailing list, as listed in the MAINTAINERS file, no longer worked. He posted a patch to point to the mailing list instead, and to remove the URL altogether. Grant Grundler replied:

The correct URL still is:

Please update the URL.

grundler <512>host has address also hosted But recently all the parisc-linux services migrated to another box. I'm not sure when/why the "old" box was disconnected or if it just crashed.

In any case, despite being at gcc-summit conf, willy did find time to migrate to the same host as IIRC, that was yesterday. The DNS just hasn't propagated yet but ISTR willy said it would today at some point.

The entire ia64-linux web site is available via anon CVS. See but use "ia64-web" instead as the repository.

I've checked out a snapshot anyone can access for now on

9. SMBIOS Driver Removed From 2.6 Kernel; Some Developers Want It Back In

4 Jun 2004 - 5 Jun 2004 (6 posts) Archive Link: "EFI-support for SMBIOS driver"

Topics: Version Control

People: David MosbergerMichael BrownGreg KHBartlomiej Zolnierkiewicz

David Mosberger said:

The patch below adds EFI support to the SMBIOS driver. Since EFI already knows the address of the SMBIOS, this avoids having to scan for the table. It also enables use of the driver on ia64 machines. The patch also adds code to handle the case where the SMBIOS table resides in memory, which is the case at least for HP's zx1-based ia64 machines. If CONFIG_EFI is off, the resulting code should be unchanged (except for replacing a readb() loop into a memcpy_fromio()).

One observation: I believe find_table_max_address() is missing some readb() calls (it's dereferencing ioremap'pped addresses directly). I didn't try to fix that since I wasn't sure why it wasn't done in the first place.

Bartlomiej Zolnierkiewicz pointed out that according to a BitKeeper patch ( , the SMBIOS driver was no longer in the tree. David replied:

Man, talk about going in circles!

If folks are serious about discouraging /dev/mem, then the SMBIOS driver makes tons of sense.

Close by, Greg KH pointed out that the driver was removed because everything it did could be done from userspace. David said, "I know full well that it can be done in user-level --- via /dev/mem, which lots of people dislike. I certainly don't feel strongly about it, but the SMBIOS driver made sense to me." At this point, Michael Brown offered:

I was the original submitter. Somebody kindly pointed out to me (offline) the error of my ways, and I was able to get my userspace lib to work just fine using mmap() instead of read(). This takes care of two out of three of the main reasons I orignally submitted this driver.

Since my library was the only user of this lib, and I no longer need it, I asked several people if it would make sense to continue to support it or to pull it. The consensus was not to "bloat" the kernel with extra stuff if it can be done via /dev/mem.

If there are strong sentiments the other way, the code is still out there if somebody else wants to take over. I looked at what it would take to add EFI support for this, and it would be trivial. I just didn't want to become yet another absentee-maintainer if I no longer need the code.

10. Improving Mousedev Button-Handling

4 Jun 2004 - 6 Jun 2004 (6 posts) Archive Link: "[PATCH 2.6] Mousedev - better button handling under load"

People: Dmitry TorokhovVojtech Pavlik

Dmitry Torokhov said:

Currently mousedev combines all hardware motion data that arrivers since last time userspace read data into one cooked PS/2 packet. The problem is that under heavy or even moderate load, when userspace can't read data quickly enough, we start loosing valuable data which manifests in:

The patch below corrects the issue - it will start accumulating new packet every time userspace is behind and button set changes. Size of the buffer is 16 packets, i.e. up to 8 pairs of press/release events which should be more than enough.

The patch is against Vojtech's tree and shuld apply to -mm. I also have cumulative mousedev patch done against 2.6.7-pre2 at:

Vojtech Pavlik was happy to see this.

11. uClinux Cross-Compiler Toolchain Updated

5 Jun 2004 (1 post) Archive Link: "[ANNOUNCE] GCC 3.4 ColdFire/ARM toolchain for uClinux (20040604)"

Topics: Backward Compatibility, FS: ROMFS

People: Bernardo Innocenti

Bernardo Innocenti said:

a new version of the uClinux cross-compiler toolchain based on GCC 3.4 is available here:

This release adds preliminary ARM support and includes binaries for Linux (both glibc23 and glibc22 distros) and Cygwin.

Many other things have been changed since the last public announcement:

Changes in release 20040605:

Changes in release 20040425:

Changes in release 20040323:

Changes in release 20040309:

Changes in release 20040112:

Changes in release 20031230:

12. Supporting SCO Binaries Under Linux

6 Jun 2004 - 9 Jun 2004 (5 posts) Archive Link: "linux-abi dead?"

Topics: Executable File Format, IBCS, Version Control

People: Steve BergmanMike JagdisEric Youngdale

Steve Bergman wanted to run an old SCO binary, and noticed that the ( project seemed dead. He asked if there were any other projects working on running foreign binaries under Linux. Later he said, "It seems that there is a patch, released just today (and just for me, I guess?) at:" Elsewhere, Mike Jagdis commented:

iBCS ceased when I decided that "enough" vendors were targetting Linux as a Tier-1 platform and what was left was legacy proprietry stuff that either worked or would be painful to fix. iBCS then became linux-abi which ported to newer kernels and added UnixWare support. I guess there just isn't enough SYSV stuff left to keep any momentum behind linux-abi anymore either...

SCO stated a long time ago that they saw nothing in linux-abi to worry them.

Which is kind of interesting because iBCS started life pretty much as a way for Eric Youngdale to test his ELF loader code, which subsequently moved into the main kernel.

(iBCS CVS is still available on even if nothing else is. It doesn't go back quite to the start - I think my initial import was 1993...)

13. Linux 2.6.7-rc3 Released

7 Jun 2004 - 8 Jun 2004 (10 posts) Archive Link: "Linux 2.6.7-rc3"

Topics: Kernel Release Announcement

People: Linus Torvalds

Linus Torvalds announced Linux 2.6.7-rc2, saying:

Ok, let's calm down for a while before the final 2.6.7.

-rc3 does a lot of sparse type cleanup, mainly thanks to Al Viro (but his work ended up getting some other people involved too, since the list of sparse warnings isn't as daunting any more). Some of that has unearthed real bugs which Al fixed.

But there are DRM, AGP, cpufreq, sparc64, and input updates there too.

14. udev 026 Released

7 Jun 2004 - 8 Jun 2004 (3 posts) Archive Link: "[ANNOUNCE] udev 026 release"

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

People: Greg KH

Greg KH announced:

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

(yes, there was a 025 release, I just forgot to announce it, full changelog is below)

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:

Major changes since 024:

Thanks 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.

15. bridge-utils Version 1.0.4 Released

8 Jun 2004 (1 post) Archive Link: "[ANNOUNCE] bridge-utils-1.0.4"

Topics: FS: sysfs

People: Stephen Hemminger

Stephen Hemminger said:

Released a new version of bridge utilities that supports both new 2.6.7 interface and older 2.6/2.4 releases. The only changes since 1.0 were internal to fix compatibility issues.

The tarball can be downloaded from:

Getting full functionality requires a build system with:

Note: libsysfs has not been fully integrated by the main linux vendors. So producing a full functional package is not possible with the default spec file.

The utilities will build (and run) on earlier systems it will just default to the old interface and which doesn't have 32/64 bit compatibility.

16. linux-libc-headers Version Released

9 Jun 2004 (1 post) Archive Link: "[ANNOUNCE] linux-libc-headers"

People: Mariusz Mazur

Mariusz Mazur announce linux-libc-headers Version, saying:

Available at


First of all sorry for the long delay - this version should be here three weeks ago, but I've been kind of busy. This shouldn't happen anymore and new version should be released no more than a week after the kernel. (yes, I know 2.6.7 will probably be here in a week or so :)

As for the addition of sanitized scsi headers - I've had some requests for it. Up until now I've encountered only one app that wanted something more than glibc had to offer and am not entirely sure if using these headers instead of glibc's won't break more things than it fixes. Test it if you like and do send a bugreport if you find that it breaks something.

17. Linus Moving To Portland, Oregon

9 Jun 2004 (2 posts) Archive Link: "Linus is moving to Portland, OR"

People: Samantha BeeAndrew Walrond

Samantha Bee said, "It's not mentioned anywhere in google news yet, but this morning's Willamette Week claims that Linus has bought a house in Portland and enrolled his kids in school here." Andrew Walrond quipped, "At least it's not Redmond ;)"







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.