Kernel Traffic #179 For 11 Aug 2002

By Zack Brown

Table Of Contents

Mailing List Stats For This Week

We looked at 1794 posts in 8549K.

There were 447 different contributors. 244 posted more than once. 175 posted last week too.

The top posters of the week were:

1. Update To Lock Assertion Patch

25 Jul 2002 - 2 Aug 2002 (11 posts) Archive Link: "[PATCH] lock assertion macros for 2.5.28"

Topics: FS: ReiserFS

People: Jesse BarnesRobert Love

Jesse Barnes posted a patch, and announced:

Here's the lastest version of the lockassert patch. It includes:

I'd be happy to take patches that implement the above routines for other architectures and/or patches that sprinkle the macros where they're needed.

Joshua MacDonald pointed out that the ReiserFS developers were looking forward to having a MUST_NOT_HOLD assertion. Jesse replied, "Well, I had that in one version of the patch, but people didn't think it would be useful. Maybe you'd like to check out Oliver's comments at and respond? If there's demand for MUST_NOT_HOLD, I'd be happy to add it since it should be easy." Robert Love also suggested implementing CAN_SLEEP and CANNOT_SLEEP assertions.

2. Status Of Serial Port Support In 2.5

28 Jul 2002 - 1 Aug 2002 (27 posts) Archive Link: "Serial core problems on embedded PPC"

Topics: Framebuffer, Modems

People: David GibsonRussell KingTom Rini

Since the new serial core code went into 2.5, David Gibson had been trying to get it working on his PowerPC (EP405 board). But the 8250 serial port on his system was giving him difficulties. He described the specific symptoms and work-arounds he was using, and also remarked, "The current plethora of similar-but-not-the-same structures describing serial ports (serial_state, serial_struct, uart_port, old_serial_port) is also rather confusing. I'm guessing some of these are deprecated and remain only as an aid to transition, but I'm not sure which." Russell King replied:

I don't see there being an easy way to kill this off:

  1. serial_struct is a userspace API.
  2. old_serial_port glues asm/serial.h into 8250.c; asm/serial.h can't be changed because (mainly) ppc uses it elsewhere. Other architectures seem to do the same sort of thing.

Unless ppc and others are willing to put up with major breakage when I change asm/serial.h, I don't see this getting cleaned up. Comments on this area welcome.

Tom Rini asked what changes Russell had in mind, and Russell said:

1. Serial port initialisation

Firstly, one thing to bear in mind here is that, as Alan says "be nice to make sure it was much earlier". I guess Alan's right, so we can get oopsen out of the the kernel relatively easily, even when we're using framebuffer consoles.

I'm sure Alan will enlighten us with his specific reasons if required.

There have been several suggestions around on how to fix this table:

a. architectures provide a sub-module to 8250.c which contains the per-port details, rather than a table in serial.h. This would ideally mean removing serial.h completely. The relevant object would be linked into 8250.c when 8250.c is built as a module.

b. we create 8250_hub6.c, 8250_generic.c, 8250_multiport.c and friends each containing the parameters for the specific cards and handle it as above.

c. make it the responsibility of user space to tell the kernel about many serial ports, and leave just the ones necessary for serial console in the kernel. (see issue 2 below)

d. we keep serial.h, make it 8250-compatible ports only, and change CONFIG_SERIAL_MULTIPORT and friends to CONFIG_SERIAL_8250_MULTIPORT This is the simplest and least likely to break other code. On the other hand, we end up hauling the ISA table and struct old_serial_port into 2.6.

2. setserial API

This is actually tied closely into another issue; I'd like to get rid of this silly idea where we're able to open serial ports that don't exist (ie, their UART is "unknown"). This behaviour appears to be for the benefit of setserial to allow it to modify port base addresses and interrupt levels, etc. Removing this facility would require a new API for such things. The best suggestion made so far is to do something like:

# echo "add 0x2e8,3,autoconfig" >/dev/serialctl
# echo "remove 0x2e8" >/dev/serialctl

(or s,/dev/serialctl,/proc/tty/driver/serial, which pre-exists)

where we have "add ioport,irq,flags" and "remove ioport" (note that mmio ports aren't covered here since they require ioremap games which tends to be card specific!)

Why make this change? Well, we have quite a lot of baggage being dragged around to support configuration of an open port and being able to open a non-existent port. I'd really like to get rid of this excess baggage.

3. /dev/ttyS*, /dev/ttySA*, /dev/ttyCL*, /dev/ttyAM*, etc

All the above are serial ports of various types. It has been expressed several times that people would like to see all of them appear as /dev/ttyS* (indeed, there was an, erm, rather heated discussion about it a couple of years ago.) I'm going to be neutral on this point here.

There are several issues surrounding this:

a. The serial core.c is very almost capable of handling this abstraction, with one exception - a registered port can only be in one group at one time. This restriction is brought about because of the way the tty layer handles its tty ports.

(Handling dual registrations in two different majors gets _really_ messy - eg, you two built-in 16550A ports and two SA1100 ports taking up ttyS0 to ttyS3. You then add a 16550A PCMCIA modem, which becomes ttyS4. Oh, and the SA1100 ports are also appearing as ttySA0 and ttySA1. _really_ messy. No thanks.)

b. serial consoles. Each hardware driver handles its serial consoles by itself, and if you have two or more hardware drivers built in with serial console support, you need to be able to tell them apart with the console= kernel parameter.

Again, this could be solvable if we have one "ttyS" view of everything (core.c would then be responsible for registering the console with printk.c and passing the various methods off to the relevant hardware).

c. People with many serial ports. We _could_ change the device number allocations such that ttyS gobbles up the ttySA, ttyCL, ttyAM, etc device numbers so we end up with the same number of port slots available for those with many many serial ports in their machines.

Various comments and criticisms followed this, but nothing was conclusively decided. See Issue #179, Section #10  (1 Aug 2002: 2.5.30 Announced; More Serial Driver Trouble) for more on this in the 2.5.30 kernel.

3. Fixing Up Source Code Style

30 Jul 2002 - 1 Aug 2002 (5 posts) Archive Link: "janitorial PATCH: 2.4: nvram.c Lindent"

People: Linus TorvaldsPavel MachekTim Hockin

Tim Hockin ran drivers/char/nvram.c through Lindent, added a few manual cosmetics of his own, and posted the patch. Linus Torvalds replied:


If you're doing these kinds of Lindent changes, you might as well also fix another non-linuxism:

        return (x);     ->      return x;

I don't know why some people seem to think that "return" is a function with an argument..

I guess that one isn't mentioned in the CodingStyles thing. I'm lazy. Bad Bad Linus.

Tim did this, and submitted two new patches, one for 2.4 and one for 2.5. Pavel Machek also suggested updating CodingStyle while he was at it....

4. Relationship Between Linux And POSIX

31 Jul 2002 - 3 Aug 2002 (36 posts) Archive Link: "manipulating sigmask from filesystems and drivers"

Topics: POSIX, Real-Time

People: Linus Torvalds

In the course of discussing whether or not various I/O operations (such as file reads) could be interrupted by signals, Linus Torvalds gave an opinion on POSIX:

POSIX is a hobbled standard, and does not matter.

We're not making a "POSIX-compliant OS". People have done that before: see all the RT-OS's out there, and see even the NT POSIX subsystem.

They are uninteresting.

Linux is a _real_ OS, not some "we filled in the paperwork and it is now standards compliant".

And being a real OS means taking the real world into account.

And the real world says that it's not acceptable to make up your own semantics, unless you have some _damn_ good reason for doing so.

5. Status Of Big File/Filesystem Support

31 Jul 2002 - 6 Aug 2002 (38 posts) Archive Link: "BIG files & file systems"

People: Peter J. BraamAndrew Morton

Peter J. Braam said that his company really wanted to use files larger than 16TB, and filesystems with more than a trillion files in them. He said, "I understand why people don't want to sprinkle the kernel with u64's, and arguably we can wait a year or two and use 64 bit architectures, so I'm probably not going to kick up a fuss about it. However, I thought I'd let you know that there are organizations that _really_ want to have such big files and file systems and get quite dismayed about "small integers". And we will fail to deliver on a requirement to write a 50TB file because of this." Andrew Morton pointed out that while it might not be such a huge task to go through the code changing each relevant 'unsigned long' to a 'pgoff_t' and tweak a few other areas, there were still some problems to getting such code accepted. He said:

Linus's objections are threefold: it expands struct page, 64 bit arith is slow and gcc tends to get it wrong. And I would add "most developers won't test 64-bit pgoff_t, and it'll get broken regularly".

The expansion of struct page and the performance impact is just a cost which you'll have to balance against the benefits. For a few people, 32-bit pagecache index is a showstopper and they'll accept that tradeoff.

Sprinkling `pgoff_t' everywhere is, IMO, not a bad thing - it aids code readability because it tells you what the variable is used for.

As for broken gcc, well, the proponents of 64-bit pgoff_t would have to work to identify the correct gcc version and generally get gcc doing the right thing.

6. Exporting Network Driver Information To /proc Or Elsewhere

31 Jul 2002 - 4 Aug 2002 (7 posts) Archive Link: "network driver informations [general NIC, Wireless and e100]"

Topics: FS: procfs, Ioctls

People: Jeff Garzik

Nico Schottelius suggested that, since the e100 network driver reported connection status, speed, and other information; it would be great to export that information to a file or directory in /proc/net. This would allow things like a status light on a window manager control panel. There were a couple of replies pointing out that the information Nico wanted was available through ioctls. Jeff Garzik added that, "Thou shalt not add to the junk collection that is procfs :). Al Viro has talked about, long term, making this information available through a filesystem. When that happens, your request will have basically been implemented."

7. 2.5 IDE: The Saga Continues

31 Jul 2002 - 1 Aug 2002 (10 posts) Archive Link: "[PATCH] 2.5.29 IDE 110"

Topics: Disks: IDE, FS: FAT, PCI

People: Marcin DaleckiPetr VandrovecAlan CoxAndre HedrickAdam J. Richter

Marcin Dalecki posted his latest IDE patch, and listed:

A couple folks objected to Marcin eliminating sector mapping support, and Petr Vandrovec added that he was actually using that legacy feature on one of his systems. He explained, "it has BIOS without LBA32, and without support for >30GB disks, but I needed to put large disk with already existing system to it, and using some disk manager was only choice (EZDrive, using 0_to_1 remap)... I know that 0_to_1 remap is broken for nr_sectors > 1, but it is hard to use loop device if system does not come up without boot manager at all." Marcin still felt that the IDE code was not the layer to handle this. He suggested, "how about handling this at partition scan time then? Partitions are after all nothing else then devices with remapped sectors in first place. Could you manage to insert at the proper place in paritions/*.c the magical + 1. It could then be turned in no instant in to a global kernel option - whch it what it is after all." He rooted around for a better understanding of Petr's system and the best way to maintain support; and after a few more posts the thread petered out.

8. EVMS 1.1.0 Released

1 Aug 2002 (1 post) Archive Link: "[ANNOUNCE] EVMS Release 1.1.0"

Topics: Disk Arrays: EVMS

People: Kevin Corry

Kevin Corry announced:

The EVMS team is announcing the next stable release of the Enterprise Volume Management System, which will eventually become EVMS 2.0. Package 1.1.0 is now available for download at the project web site:

EVMS 1.1.0 has full support for the 2.4 kernel, and includes patches for most kernels up to 2.4.19-rc3. It also has nearly full support for the 2.5 kernel, and includes patches for kernels 2.5.25 and 2.5.27.

**** Important Note ****

As of this release, EVMS has been assigned a new, permanent major number: 117. The previous major number, 63, was reserved for experimental drivers. Before using 1.1.0, please read the README_Upgrade_To_1.1.0 file included in the source package for details on how you might be affected by the major number change. You can also view these instructions on the EVMS web site at


For on-going performance testing and analysis results for EVMS, please visit the Linux Scalability Effort site at:

Please send any questions, problem reports or bugs to the EVMS mailing list: ( .

There was no reply.

9. syscalltrack 0.73 ALPHA Released

1 Aug 2002 (1 post) Archive Link: "ANN: syscalltrack 0.73 "August Penguin" released"

Topics: User-Mode Linux

People: Muli Ben-YehudaMuli

Muli Ben-Yehuda announced:

syscalltrack-0.73, the 9th _alpha_ release of the Linux kernel system call tracker, is now available. syscalltrack supports version 2.4.x of the Linux kernel on the i386 and UML architectures. Kernel versions 2.2.x and 2.5.x should work as well, but did not receive the same extensive testing. The current release contains a new experimental strace compatible tool, sctrace, a logging device file, several bug fixes and many new system calls, including all of the IPC syscalls. More details below.

* What is syscalltrack?

syscalltrack is made of a pair of Linux kernel modules and supporting user space environment which allow interception, logging and possibly taking action upon system calls that match user defined criteria. syscalltrack can operate either in "tweezers mode", where only very specific operations are tracked, such as "only track and log to delete /etc/passwd", or in strace(1) compatible mode, where all of the supported system calls are traced. syscalltrack can do things that are impossible to do with the ptrace mechanism, because its core operates in kernel space.

* Where can I get it?

Information on syscalltrack is available on the project's homepage:, and in the project's file release.

The source for the latest version can be downloaded directly from: or any of the other sourceforge mirrors.

* Call for developers:

The syscalltrack project is looking for developers, both for kernel space and user space. If you want to join in on the fun, get in touch with us on the syscalltrack-hackers mailing list (

There was no reply.

10. 2.5.30 Announced; More Serial Driver Trouble

1 Aug 2002 (21 posts) Archive Link: "Linux 2.5.30"

Topics: FS: NFS, Kernel Release Announcement, SMP

People: Linus TorvaldsAdam J. RichterRussell KingAxel SiebenwirthTheodore Y. Ts'o

Linus Torvalds announced 2.5.30 and posted the ChangeLog ( , saying:

Tons of stuff all over the map again. Lots of merging with various people.

The most noticeable fix (for me personally) was Trond fixing a nasty RPC problem that caused the NFS client to return bogus dentry pointers that hung the VFS layer hard on SMP machines.

But as you can see from the "short" changelog version (the full one is 63kB), there's a lot of other stuff there.

Continuing from Issue #179, Section #2  (28 Jul 2002: Status Of Serial Port Support In 2.5) , Axel Siebenwirth pointed out that the 8250.c file failed to compile as a module. There were some initial questions, and then Adam J. Richter explained:

linux-2.5.30/include/linux/serialP.h needs struct async_icount, which is defined in <linux/serial.h>, causing linux-2.5.30/drivers/serial/8250.c not to compile, among other problems. In linux-2.5.30, you cannot compile a file that includes <linux/serialP.h> without including <linux/serial.h>. So, I think the solution is for serialP.h to #include serial.h. I have attached a patch that does this.

From the comments in serialP.h, it looks like there was some effort in linux-2.2 to allow inclusion of serialP.h without serial.h, but I see no indication of what benefit that was supposed to provide.

Ted (or whowever gathers drivers/serial patches for Linus), do you want to shepherd this change to Linus, do you want me to submit it directly, or do you want to do something else?

Russell King took a look, and said:

Ack. I've just found why I and many other people can build it, and other people can't. I can tell you that you're building 8250.c as a module.


When I build 8250.c into the kernel, linux/module.h doesn't include linux/version.h, so when we include linux/serialP.h, the compiler assumes that LINUX_VERSION_CODE is zero. So we end up including linux/serial.h.

However, when building as a module, linux/module.h does include linux/version.h, so when we don't include linux/serial.h.

Oh, the problems of trying to reduce the includes... I think we should re-include linux/serial.h and eliminate linux/serialP.h.

Hmm, I wonder how many other oddities like this are in the tree today. It sounds like we want to create a rule similar to the one for using CONFIG_* symbols. Does this sound reasonable: if you use LINUX_VERSION_CODE, you must include linux/version.h into that very same file to guarantee that it is defined.

Well, I took and created (attached). Oh god, can I please put the worms back in the can? Now? I think there's lots of work to do here; lots of stuff including linux/version.h for the hell of it, and a comparitively small number not including it when they use LINUX_VERSION_CODE.

He posted his own fix and said that he was the person (Instead of Adam's idea of Theodore Y. Ts'o) to push these changes off to Linus. Russell warned folks not to send his patch to Linus but only to test it, as he had other stuff to include as well.

11. CS4281 Sound Driver Cleanup In 2.4 And 2.5

1 Aug 2002 - 2 Aug 2002 (3 posts) Archive Link: "cs4281 driver cleanup (includes synchronize_irq() update)"

People: David MosbergerAlan Cox

David Mosberger posted a patch for 2.5 and said, "The patch below cleans up the cs4281 sound driver to compile cleanly (no warnings) on 64-bit platforms such as ia64. Also, the patch updated the calls to synchronize_irq() according to the new interface (which takes an irq number as an argument). Someone who understands this driver might want to double check that this is indeed working as intended." Alan Cox said he'd do the double checking, then port the whole patch back to 2.4.

12. MMU-less Patches

1 Aug 2002 - 5 Aug 2002 (10 posts) Archive Link: "[PATCH]: linux-2.5.30uc0 MMU-less patches"

People: Greg UngererDave Jones

Greg Ungerer announced:

I have a new set of uClinux (MMU-less) patches for 2.5.30 at:

I have coded a generic MTD map driver to replace the old crufty blkmem driver. The blkmem driver will be going away in future patches.

Other than that it is still all working nicely.

Dave Jones didn't very closely examine the code, but said it looked as though more could be shared between Greg's code and the normal memory management code. Greg replied:

there is actually a lot in common. Probably something like 70%. This is really a question of organization.

I would much prefer to see the non-mmu support in with mm. But it would mean a few #ifdef's in there to allow for the differences.

Dave replied, "Versus massive code duplication, I think the ifdef's would be a better approach, especially if you can hide them away in headers."

13. Status Of Toshiba Laptop Support In 2.5

2 Aug 2002 - 3 Aug 2002 (6 posts) Archive Link: "[PATCH] Toshiba Laptop Support and IRQ Locks"

People: Alan Cox

John Weber saw that Toshiba laptop support was broken in 2.5.30, and posted a patch to fix it. Alan Cox thought the patch looked "basically sound", and offered some implementation suggestions. John posted a new patch, and the thread ended.

14. Status Of Generic RTC Driver For 2.5

2 Aug 2002 (1 post) Archive Link: "[PATCH][RESEND] A generic RTC driver [0/3]"

Topics: SMP, Version Control

People: Tom RiniPaul MackerrasGeert UytterhoevenDave Jones

Tom Rini posted his generic RTC driver patch, saying:

The is a slightly updated version of the patch that I've resent twice split up into 3 chunks, and 3 times as a single patch. The only changes this time are support for a 64bit kernel and a 32bit userland, from the parisc group, as well as include/asm-parisc/rtc.h, both from Randolph Chung.

Patch 1 is the current version of the driver (switched to C99-style initializers, done in the current m68k CVS tree) and needed changes to select/compile it in general. I had previously asked the m68k community if anyone objected to this being submitted by me, and I got Richard Zidlicky's (who's at the top of the file) approval, as well as Geert Uytterhoeven's approval.

Patch 2 is the PPC portion of the patch, which creates include/asm-ppc/rtc.h. This has been in the PPC bitkeeper tree for over a month now. I can have Paul Mackerras send this to you instead, if you prefer.

Patch 3 is my own slight bit of work, as well as some work by Randolph Chung. This changes set_rtc_time(struct *rtc_time) to return an int instead of void. This was done so that the arch-specific code here could do additional checks on the time and return an error if needed. This then introduces include/asm-generic/rtc.h, include/asm-i386/rtc.h and include/asm-alpha/rtc.h. include/asm-generic/rtc.h contains the get_rtc_time and set_rtc_time logic that is in drivers/char/rtc.c and has been tested on SMP i386. This also modifies include/asm-ppc/rtc.h to return -ENODEV if no rtc hardware is present.

Additionally, Dave Jones pointed out to me a place where we might not be safe when jiffies wraps, so this switches that to time_after().

From Randolph Chung, is supprt for a 64bit kernel and a 32bit userland.

And now onto the history of this driver.

This has been in the m68k tree for a number of years now, so the general code behind it is quite sound. This has also been abstracted to the point where it works on other archs (mainly due to m68k/PPC hybrid machines). This is quite useful since a number of archs cannot use drivers/char/rtc.c because they have very different hardware, or other issues.

This should also be useful on MIPS, who at one point in the past were about to copy the PPC rtc driver (drivers/macintosh/rtc.c) and quite probably useful on other archs as well.

This has been in use by the parisc-linux people as well for some time, and a version similar to this has been tested by them in 2.5.

Based on some private feedback, I believe with some additional enhancements, ia64 will make use of this as well. And if the MIPS community ever did make an rtc driver similar to drivers/macintosh/rtc.c, they should be able to use this one rather trivially.

There was no reply.

15. User-Mode Linux For 2.5.30 Released

2 Aug 2002 (1 post) Archive Link: "UML 2.5.30"

Topics: User-Mode Linux

People: Jeff Dike

Jeff Dike announced:

UML has been updated to 2.5.30 and UML 2.4.18-49. Most of the UML-specific stuff has been in hppfs, which isn't in this patch. The exception is a fix for a crash caused by killing a UML xterm.

Since UML didn't make 2.5.30, I'll be sending this patch in to Linus.

The patch is available at

For the other UML mirrors and other downloads, see

Other links of interest:

The UML project home page :
The UML Community site :

There was no reply.

16. Source Tarball Unpacking Conventions

2 Aug 2002 - 6 Aug 2002 (10 posts) Archive Link: "Linux v2.4.19"

People: Alan CoxBill DavidsenMarcelo TosattiJames W. Laferriere

Marcelo Tosatti announced 2.4.19 ( , being an unchanged copy of 2.4.19-rc5. James W. Laferriere noticed that the tarball unpacked into a directory called linux-2.4.19/ instead of the normal linux/ directory. Alan Cox said, "Kernels until recently did always unpack into linux/. Linus changed and I'm happy Marcelo has followed suit, its much more sensible the new way." And Bill Davidsen added, "Let's hope the major fix trees like -aa and -ac follow the convention. I have no problem with the change (since I keep my stuff that way) but I hope it is pervasive."

17. New Linux/x86/64 Snapshot From 2.4.19

3 Aug 2002 (1 post) Archive Link: "2.4.19 based linux kernel snapshot for x86-64"

People: Andi Kleen

Andi Kleen announced:

A new linux/x86-64 snapshot based on linux 2.4.19 has been released. For more information on x86-64 see

Full tar ball: (still uploading, will soon appear on server)

Patch against normal 2.4.19 from
55331b0973fe86549102b0ca720be109 x86_64-2.4.19-1.bz2


There was no reply.

18. i8xx Updates For 2.5.30; BitKeeper Policy

3 Aug 2002 (4 posts) Archive Link: "i8xx series patches for 2.5.30"

Topics: Disks: IDE, PCI, Sound: i810, Version Control

People: Wim Van SebroeckLinus Torvalds

Wim Van Sebroeck said to Linus Torvalds:

I just sent you 6 bitkeeper patches for the i8xx series chipsets. The patches are:

  1. This patch contains pci.ids updates for the i8xx chipsets
  2. This patch makes the i810_rng Documentation the same as it is in 2.4.19
  3. This patch adds a set of defines to pci_ids.h for 82801E and 82801DB I/O Controller Hub PCI-IDS. I could not add them all since two of them existed allready for the IDE controllers, but the naming was not ideal. That's why patch 5 and 6 corrects this.
  4. This patch updates the i810-tco module to the same level as it is in 2.4.19 now.
  5. This patch corrects the PCI-ID define for the 82801DB IDE controller.
  6. This patch corrects the PCI-ID define for the 82801E IDE controller.

Linus replied, "Please don't use "bk send" to send me bitkeeper patches. They are totally unreadable, they are harder to integrate than the alternatives (regular patches or BK trees to be pulled), and they cause my inbox to have totally nondescript Subject: lines, so I delete them automatically."

19. NTFS Backport To 2.4

3 Aug 2002 (1 post) Archive Link: "[ANNOUNCE] NTFS 2.0.22a for Linux 2.4.19"

Topics: FS: NTFS

People: Pawel Kot

Pawel Kot announced:

New version of the NTFS-TNG backport is out. This version syncs with both: the latest NTFS driver -- 2.0.22 and the latest Linux kernel -- 2.4.19.

You can get the patch from the sourceforge servers. See the detailes at

There was no reply.

20. Errata Page For 2.4 Kernels

4 Aug 2002 - 5 Aug 2002 (6 posts) Archive Link: "2.4.19 make allyesconfig - errors and warnings"

Topics: Samba

People: Tomas SzepeAlan Cox

In the course of discussion, Tomas Szepe remarked, "wouldn't it be useful to have dedicated errata pages for recent stable kernels where important patches (such as the 2.4.18 personality fix, 2.4.18 samba oops fix or the upcoming 2.4.19 ide updates) would be published? Finding a link to these in the kernel FAQ, people would just patch their kernels instead of posting to lkml, which could cut on the amount of duplicate bugreports significantly plus folks wouldn't have to wait 6 months+ for an official update to get rid of an oops." Alan Cox replied, "I did that for some of the 2.2 trees. I can keep an errata page on for the 2.4.19 tree as well if people want. Right now the errata would be pretty small so its easy to deal with."

21. Changes To 2.4 USB Configuration Options

4 Aug 2002 (2 posts) Archive Link: "2.4.19, usb mouse is gone"

Topics: USB

People: Brad HardsFelix Seeger

An alarmed Felix Seeger noticed that his USB mouse stopped working after upgrading to 2.4.19. Brad Hards pointed out that 2.4.19 added a new config option, CONFIG_USB_HIDINPUT, which had to be set for USB mice. He added, "Checking the mailing list archives would have been productive too."

22. ACPI And Software-Suspend

4 Aug 2002 (4 posts) Archive Link: "2.5.30 ACPI: fixing compilation"

Topics: Power Management: ACPI, SMP

People: Pavel Machek

Pavel Machek posted a short patch and said, "This fixes compilation and is actually right since we can't get SMP machine suspending, anyway. We'll have to bring all other CPUs down for suspend in future. Please apply." Someone asked what part of the code ensured that suspending an SMP machine could never happen. Pavel replied, "It was broken before so I left it broken. Second CPU will probably kill it fast enough not to corrupt data too badly." The same person suggested making the software-suspend code depend on CONFIG_SMP not being set. There was no reply.

23. Major 2.5 NTFS Update

4 Aug 2002 (1 post) Archive Link: "[BK-2.5-PATCH] NTFS: 2.0.23 - Major bug fixes (races, deadlocks, non-i386 architectures)"

Topics: FS: NTFS, Version Control

People: Anton Altaparmakov

Anton Altaparmakov said:

Linus, please do a

bk pull


This is quite a massive bug fix update. I have a dual athlon with 3G RAM to play with at the moment so have been able to iron out a lot of races, recursive locking, and subsequent deadlocks.

This should also fix the reported ntfs over loopback i/o error problems. At least I can no longer reproduce the errors after I added the optimization barrier() in fs/ntfs/compress.c. I suspect gcc screws up without it...

There was no reply.

24. Status Of HFS In 2.4 And 2.5

5 Aug 2002 (3 posts) Archive Link: "HFS-Bug in 2.4.19"

People: Alan CoxBenjamin Herrenschmidt

Wolfgang Pichler submitted a bug report against the 2.4.19 HFS code, adding that it was the 4th time he'd submitted the identical report since 2.4.8; Alan Cox replied, "HFS is not maintained. It will probably go away for 2.6 unless someone becomes its maintainer and fixes it." And Benjamin Herrenschmidt added, "I noticed Al finally burned me on this as he did some locking fixes to HFS in 2.5. I'm pretty sure more is needed, and I still have some plans to fix some of it, in both 2.4 and 2.5, it's just that so far, I've always found more important things to do of my linux dedicated time ;)"

25. Status Of 2.5 PowerPC offb And atyfb Drivers

5 Aug 2002 (1 post) Archive Link: "[PATCH] fix some FB drivers used on PPC"

People: Paul Mackerras

Paul Mackerras posted a patch and said, "Here is a patch which gets the offb and atyfb drivers to compile and run on PPC. The patch is against 2.5.30. I also have patches for aty128fb and radeonfb but they are more extensive and I want to work on them a little more." There was no reply.

26. Status Of Maestro3 Sound Driver In 2.5

5 Aug 2002 (2 posts) Archive Link: "[PATCH] 2.5.30 Maestro3"

Topics: Sound: Maestro, Sound: OSS

People: Marcin DaleckiAlan Cox

Marcin Dalecki posted a patch and said:

The attached patch is updating the Maestro3 OSS sound chip driver to

  1. The changes in IRQ handling.
  2. C99 standard conformant initializers.

But Alan Cox said, "This is insufficient. It has to lock against card interrupts and other arbitary ill defined (in 2.4 anyway) suspend things. Assuming the PM layer can mind its own business nowdays you are at least going to want to take the card lock. I think thats mostly sufficient for the maestro case. There is a long standing question about whether the resume code should end by calling the irq handler to fake any missed IRQ pending over the suspend of the card - but thats also true in the 2.4 case." End Of Thread (tm)

27. Adding Cobalt Support To NVRAM Driver

5 Aug 2002 (1 post) Archive Link: "[PATCH] nvram - add Cobalt support"

Topics: Version Control

People: Tim Hockin

Tim Hockin posted a patch and said, "This patch adds support for Cobalt systems to the nvram driver. In the process, the nvram symbols were exported, and a few other minor cleanup went in. This iwll soon be available through bk, but I thought I'd solicit any gripes before I push it up. :) This is another in a series of patches trying desperately to get our tree synced :). If it all looks ok, I'll ask Marcelo and Linus to pull it." There was no reply.

28. Status Of /proc/partitions In 2.4 And 2.5

6 Aug 2002 - 7 Aug 2002 (7 posts) Archive Link: "[PATCH] conditionally re-enable per-disk stats, convert to seq_file"

Topics: FS: driverfs

People: Christoph HellwigKurt GarloffAndries BrouwerRandy Dunlap

Christoph Hellwig posted a patch and said, "This patch against 2.4.20-pre1 converts /proc/partitions to the seq_file interface as in 2.5, makes it report the sard-style extended disk statistics condititional on CONFIG_BLK_STATS and disables the gathering of those totally otherwise to not waste memory and processing power." Kurt Garloff, author of the original code Christoph had back-written, added, "Actually, I was expecting criticism due to the ifdef stuff I did and was prepared to come up with something better. But I also learned never to put effort into something before being asked to ... Your patch looks fine to me. Thanks for preparing it!"

Andries Brouwer pointed out that /proc/partitions might not be the best place for this data. He said, "Maybe /proc/partitions can go away eventually with all info available under driverfs or so. But for the time being, /proc/partitions is used, and some changes are planned to make identification of the devices involved easier. It is really ugly to stuff a lot of garbage into a file just because it happens to exist already. If you want disk statistics, why not put it in /proc/diskstatistics?" Christoph replied that the user-space tools expected to find the data in /proc/partitions, but Andries came back with, "You create a mess in the official kernel because your user space tools are broken? And it is easier to patch the kernel than to fix them, even though you'll have to fix them eventually? And fixing these tools consists of replacing one filename?"

Elsewhere, Randy Dunlap also thought the data should go in a different place, and Christoph replied, "Feel free to implement it. This is the interface use by all major vendors for ages and the -ac kernel series. It's supported by unpatched upstream performace tools. I'll keept this patch around for the few poort soul complaining that they don't get that's anymore after upgrading to the latest source."

29. LSM Updates For 2.4 And 2.5

6 Aug 2002 (2 posts) Archive Link: "[ANNOUNCE] 2.5.30-lsm1"

Topics: Version Control

People: Chris WrightAnton BlanchardMatthew WilcoxStephen SmalleyGreg KHJames Morris

Chris Wright announced a Linux Security Modules update for 2.5:

The Linux Security Modules project provides a lightweight, general purpose framework for access control. The LSM interface enables security policies to be developed as loadable kernel modules. See for more information.

2.5.30-lsm1 patch released. This is a rebase to 2.5.30 as well as the continuation of merging LSM with mainline.

Full lsm-2.5 patch (LSM + all modules) is available at:

The whole ChangeLog for this release is at:

The LSM 2.5 BK tree can be pulled from: bk://


There was no reply to this, but elsewhere, under the Subject: [ANNOUNCE] 2.4.19-lsm1 ( , he announced an LSM update for 2.4:

2.4.19 lsm patch released. This is includes bugfixes and merging up to the current stable 2.4 Linux tree.

Full lsm-2.4 patch (LSM + all modules) is available at:

The whole ChangeLog for this release is at:

The LSM 2.4 stable BK tree can be pulled from: bk://


There was no reply to that either.

30. August 7 Status Page

6 Aug 2002 (1 post) Archive Link: "[STATUS 2.5] August 7, 2002"

Topics: Feature Freeze

People: Guillaume Boissiere

Guillaume Boissiere linked to his August 7 status page ( , saying, "Getting fancy with colors this week. I marked all the post-feature freeze items in grey in the list. If I missed some, let me know." There was no reply.

31. kdb Update For 2.4

7 Aug 2002 (1 post) Archive Link: "Announce: kdb v2.3 is available for kernels 2.4.18 and 2.4.19"

Topics: USB

People: Keith Owens

Keith Owens announced the availability of kdb v2.3 for 2.4.18 and 2.4.19, at He added, "These patches are alpha quality, they have had limited testing. The usb keyboard code crashes on ia64 for me, set CONFIG_KDB_USB=n unless you feel like fixing the problem." There was no reply.

32. MatroxFB Update For 2.5

7 Aug 2002 (1 post) Archive Link: "FYI: [BK PATCH] matroxfb update: G450/G550 DVI and TV support"

Topics: Framebuffer, Version Control

People: Petr Vandrovec

Petr Vandrovec announced:

I just sent changeset below to the Linus. If you are using my patches for TV-Out from, please note that V4L2 support for setting brightness/contrast and other features is NOT part of this patch. I'll send it to Linus after V4L2 interface finds its way into the 2.5 kernel.

And also, as you may guess, driver is not ported to the new fbdev API.

Patch and bkpatch were removed from this copy of message - it is 129KB file. You can download it from, or you can look at, or you can pull from bk:// or ... It applies cleanly to the currently available 2.5 tree.

There was no reply.







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.