Kernel Traffic
Latest | Archives | People | Topics
Latest | Archives | People | Topics
Latest | Archives | People | Topics
Home | News | RSS Feeds | Mailing Lists | Authors Info | Mirrors | Stalled Traffic

Kernel Traffic #178 For 4 Aug 2002

By Zack Brown

Table Of Contents

Mailing List Stats For This Week

We looked at 1904 posts in 8822K.

There were 481 different contributors. 244 posted more than once. 171 posted last week too.

The top posters of the week were:

1. Origins Of The 'GNU/Linux' Naming Debate

18 Jul 2002 - 30 Jul 2002 (41 posts) Archive Link: "Alright, I give up. What does the "i"in "inode" stand for?"

Topics: Microkernels: Hurd

People: Kelsey HudsonRob Landley

In the course of discussion, Rob Landley confessed to being the cause of Richard Stallman's crusade to call Linux 'GNU/Linux'. Kelsey Hudson had remarked earlier, "as much as i respect the guy for his contributions to the open source movement, i can't help but ask myself why he's such a baby about the little things like that." And Rob replied:

Um, because I sort of tried to explain marketing to him, back when I was a contractor at IBM in late 1998? (For which I would like to apologize to the community at large. I MEANT well...)

Okay, time to come clean. Back then the fsf web page had a whole "don't call the OS linux!" section, and I emailed Stallman to object. Linux was a recognizable and growing operating system brand name, while the Gnu project was largely seen as a tool vendor in the wider community and "Hurd" meant nothing to most people (it could be a game or a spreadsheet for all we knew, or a floor wax for that matter). So fighting against the Linux name was explicitly counterproductive from a marketing standpoint. If we wanted to get people to use "Linux", they had probably at least heard of it. Saying "It's not Linux!" would just confuse them. Stallman's anti-linux crusade was diminishing one of free sotware's single biggest assets.

The REASON he wanted to do this, according to his web page, was that the hurd would replace the linux kernel. I told him that if he really did want to position "Gnu Hurd" as an upgrade to "Gnu Linux", as his web page said, he first had to attach the GNU name to Linux, sort of like "kellog's raisin bran", "bud lite", or the way the "Turbo" name allowed Borland to sell many different types of compilers under one family (Turbo Basic, Turbo Pascal, Turbo C, Turbo C++. Or Kellog's Rasin Bran, Bud Lite, etc...)

I exchanged three or four emails with him, and he agreed to stop trying to stop the use of the word Linux and instead promote the GNU organization more, and highlight its achievements and contributions to Linux. It seemed like a good thing at the time...

I would like to apologize to the community at large. I kind of got buried in work and dropped my half of the conversation for a month or two, and then this "GNU/Linux" thing hit the headlines and I winced a lot. It had turned into an ego thing and he'd completely missed the marketing point I'd been trying to make, he had no product to promote except himself and blowing your own horn has ramifications that deprive it of effectiveness... Anyway, I emailed him again and tried to go over some of the problems with his first attempt at marketing, but he was on the road and buried in email, and generally wasn't listening anymore...

I was also naieve enough back then that I didn't realise the marketing niche I was pointing him at was already filled by distributions: Red Hat Linux, Slackware Linux, etc. The last distribution I'd used at that point was SLS. :) I actually thought the FSF was trying to put out a Linux distribution. (Well they did -- Debian -- but the project forked away and disassociated itself from them politically. (Lots of projects seem to do that...) I think the FSF's web page was a bit out of date when I was trying to catch back up on Linux after a long digression into OS/2 and Java. Although Debian is still sort of aligned with the FSF, and as such is the only Linux distribution to listen to stallman enough to slap GNU/ on their official name. Or to try to make the Hurd actually run. I think it was debian's web page that pointed me back to at the time, actually...)

So now you know. Once again, I am deeply sorry. At least he stopped telling people not to use the word "Linux" at all for the name of the OS...

2. ACPI PCI Driver Patched Up To 2.4.19-rc2-ac2

19 Jul 2002 - 26 Jul 2002 (3 posts) Archive Link: "[PATCH] ACPI PCI Hotplug driver update for 2.4.19-rc2-ac2"

Topics: Hot-Plugging, PCI, Power Management: ACPI

People: Greg KH

Greg KH gave a link to ACPI PCI Hotplug driver update, written by Takayoshi KOCHI and tested on IBM i386, NEC i386, and various ia64 machines. Takayoshi replied with a small additional patch that had somehow been missed in his original submission. Greg added it to his tree.

3. Support For Kernel Probes

19 Jul 2002 - 25 Jul 2002 (2 posts) Archive Link: "[PATCH] Kernel probes for i386 2.5.26"

Topics: Assembly, SMP

People: Rusty RussellSuparna BhattacharyaVamsi Krishna S

Rusty Russell posted a patch by Vamsi Krishna S and explained, "This is a neat patch by Vamsi which allows code to trap on kernel instructions. The IBM guys have stuff for non-intrusive testing, debugging, instrumentation on top of this. It's also nice to insert assertions in core code without having to reboot 8)" . Suparna Bhattacharya replied, "Here is a somewhat brief writeup we had available about kernel probes - hope it helps provide a little more information as suggested by some people offline." She posted:

Kernel Dynamic Probes

Kernel Dynamic Probes (kprobes) provides a lightweight interface for kernel modules to implant probes and register corresponding probe handlers. A probe is an automated breakpoint that is implanted dynamically in executing (kernel-space) modules without the need to modify their underlying source. Probes are intended to be used as an ad hoc service aid where minimal disruption to the system is required. They are particularly advocated in production environments where the use of interactive debuggers is undesirable. kprobes also has substantial applicability in test and development environments. During test, faults may be injected or simulated by the probing module. In development, debugging code (for example a printk) may be easily inserted without having to recompile to module under test.

With each probe, a corresponding probe event handler address is specified. Probe event handlers run as extensions to the system breakpoint interrupt handler and are expected to have little or no dependence on system facilities. Because of this design point, probes are able to be implanted in the most hostile environments -- interrupt-time, task-time, disabled, inter-context switch and SMP-enabled code paths -- without adversely skewing system performance.

kprobes Interfaces

kprobes provides two interfaces: register_probe and unregister_probe.


Registration defines the probe location, which must be at an instruction boundary that precedes any associated opcode prefixes. It also defines three call-back addresses for the probing module:

register_probe passes a struct kprobe:

struct kprobe {
       u8 * addr;      /* location of the probe point */
       spinlock_t lock;
       struct list_head list;
       unsigned long status;
        /* Called before addr is executed. */
       kprobe_pre_handler_t pre_handler;
       /* Called after addr is executed, unless... */
       kprobe_post_handler_t post_handler;
        /* ... called if executing addr causes a fault (eg. page fault).
         * Return 1 if it handled fault, otherwise kernel will see it. */
       kprobe_fault_handler_t fault_handler;
       u8 opcode;

the location of the probepoint, which must be at an instruction boundary including any associated opcode prefixes - referencing label in C will guarantee this.

the function that will be called when the probed instruction is about to execute.

the function that will be called on completion of successful execution of the probed instruction

the function that will be called if any software exceptions occur

The user is required to retain this structure in resident memory for as long as the probe remains active. Some of the fields are used internally by kprobes and must be initialised to NULL or ZERO. The fields the user is required to initialise are the addr and the pre_handler fields. The post_handler and fault_handler are optional.


unregister_probe also requires struct kprobe. The user has to unregister explicitely all registered probes before removing the probe handling module.

Extensions to Kernel Dynamic Probes

Kernel Dynamic Probes has been developed from the full Dynamic Probes patch. It includes the essential mechanism to allow probes to exist in kernel space. The RPN Language Interpreter, Watchpoints and User-space probes extensions, which are part of the Dynamic Probes Package, will be available as add-on patches from the Dynamic Probes web-site.

4. Kludging Around APIC Problems

22 Jul 2002 - 26 Jul 2002 (17 posts) Subject: "Summit patch for 2.4.19-rc3-ac2"

Topics: SMP

People: Mikael PetterssonJames CleverdonSteven ColeZwane Mwaikambo

Steven Cole submitted a patch for developers who had noticed a lot of APIC errors beginning at around the 2.4.19-rc1-ac6 time-frame. A number of people said this patch nailed the problem for them; but Zwane Mwaikambo reported SMP-related lockups on that kernel, not necessarily caused by Steven's patch, but not fixed by it either. He confirmed that the system ran fine with 2.4.19-rc2, but he didn't have much more information about what actually went wrong with the broken kernel. James Cleverdon posted a patch and suggested Zwane give it a try; but Zwane felt some of the patch was too drastic. Mikael Pettersson said, "Drastic is an understatement. Try "gross". Sane machines running correct code shouldn't throw local APIC errors. If something's causing errors, that something should be fixed, not hidden. I hope that was just a temporary debug hack and not part of the design..." James explained:

On the contrary, when Intel moved the local APIC from a separate chip onto the CPU around the time of the P54C, they hobbled it. Formerly, it could accept and latch any number of interrupts because it contained three bit vectors that could store all the necessary state info. The P54C (and later) version had two latches per interrupt level. The level was defined as the top nibble of the interrupt vector. So, P54Cs could only latch two interrupts for, say, the 0x31-0x3F range for ISA IRQs. Too bad if three 0x3X interrupts arrive. Number 3 cannot be latched.

Intel added new error states to the local APIC and the bus protocol to allow for interrupts to _not_ be delivered, thanks to the latch limit. On a busy system with lots of interrupts, you will sometimes see several of these receive accept errors per day. There is nothing you can do to fix the condition, aside from processing all . It really is more of a warning than an error.

On our NUMA P6 box, we found that the local APICs would occasionally start spasming with error interrupts. An APIC bus analyzer didn't show any kind of errors on the APIC bus. They would just weird out and all attempts to clear the error had no effect. We never did find a solution to that one or get an adequate explanation from Intel. The only kludge that worked was to turn off the APIC error interrupt.

Naturally, the cleaned up version of the apic_state_dump patch wouldn't do that, or would make it an option.

The discussion petered out here.

5. Watchdog API Enhancements Planned

23 Jul 2002 - 27 Jul 2002 (9 posts) Archive Link: "Handling NMI in a kernel module"

People: John LevenAlan CoxJonathan Lundell

Francois Isabelle asked if the i386 kernel exported API to drivers, to request a non-maskable interrupt (NMI) the way one could already make an interrupt request (IRQ). His company was working on a dual stage watchdog, which would watch for and respond to system lockups, and he wanted to know if the kernel supported this. John Leven replied, "Not currently, no." He suggested, "You can do some horrible hack with sidt + _set_gate() to replace the NMI trap handler," but added that he'd love to see a cleaner solution. Alan Cox also said to Francois, "We have a watchdog API but not yet dual stage stuff. Its becoming a must have for HA stuff so the API needs extending." Alan Robertson announced a new mailing list to talk about enhancements to the watchdog API. Alan remarked in reply, "I've been tracking other lists. The current state is very much that we need the dual notifier. I now have some draft code that allows us to do this even on hardware that doesn't support it, and where the read() function gets told when an event is about to occur." Jonathan Lundell got all hot to see the code, but the discussion petered out.

6. Floppy Code Broken For A Long Time In 2.5

24 Jul 2002 - 25 Jul 2002 (9 posts) Archive Link: "[BUG] 2.5.27 floppy driver"

Topics: FS: ext2

People: Mikael PetterssonDiego Calleja

Nico Schottelius reported that the 2.5.27 kernel was not handling the floppy drive correctly. Someone replied that it was broken and would stay broken until someone decided to fix it. Nico suggested just reverting the code to the most recent working version, 2.5.25, but the same person replied that the code had been broken by some VFS fixes that had gone in, so it wasn't just a simple problem of reverting to an earlier state. Diego Calleja pointed out that the most recent VFS updates were in 2.5.22, and the unnamed person agreed, saying that the floppy code had been broken for quite awhile, and that the problem was very well known. Nico replied that he'd been able to use the floppy code more recently than 2.5.22; but there was no reply. Elsewhere, the unnamed person said that in his/her experience, the most recent kernel with working floppy code was 2.5.7; but he/she remarked that going back to such an early stage of 2.5 development could be quite risky in other ways as well.

Far, far away, under the Subject: [PATCH][2.5.28] broken floppy driver workarounds, take 4, Mikael Pettersson posted a patch and said:

Here's the 4th version of my patch to "fix" the floppy driver which got broken by the 2.5.13-2.5.19 and 2.5.28 block dev changes.

In 2.5.28 there was a change in fs/block_dev.c which set the floppy block dev's size to 0, and this causes ENOSPC errors on writes to the floppy dev. This 4th version of the patch adds a workaround for this problem.

Partial VFS access _may_ work now. I created an ext2 fs on /dev/fd0 under 2.5.28+this patch, and it fsck'd ok under both 2.5.28 and 2.4.19rc3. However, when I attempted to put lilo on that floppy the kernel oopsed with a "buffer layer error at buffer.c:403", so things are still not quite right.

7. agpgart Maintainership

24 Jul 2002 - 25 Jul 2002 (4 posts) Archive Link: "[BK PATCH] agpgart changes for 2.5.27"

People: Greg KHLinus TorvaldsDave JonesRusty Russell

Greg KH posted a patch from Rusty Russell for the agpgart code, and remarked, "Seems that some people think that I'm the person to send agpgart patches to as I touched it last, when will I ever learn..." Linus Torvalds replied, "Heh. "Tag, you're it"." And Dave Jones added:

Conspiracy theorists may suggest I had this planned when I convinced you to push the split-up work. Heh.. Excellent 8-)

Truth be told though, despite agpgart having a maintainer, and Jeff popping up on dri-devel once a month or so, it's pretty much been hacked on by everyone and his dog since Jeff last touched it, so I don't think you have too much to worry about by being "it" 8-)

8. 2.5 Problem-Report Status Page

24 Jul 2002 - 25 Jul 2002 (2 posts) Archive Link: "2.5 Problem Reports Status"

Topics: Disks: IDE

People: Thomas MolinaDaniel Phillips

Thomas Molina gave a link and announced:

Here is a followup on a little project I've been playing around with for the past few days. This project is to track problem reports, oops, bugs, etc for the devleopment kernel. Hopefully it will prove useful. Several points about this:

Daniel Phillips replied, "so long as you have the energy, go for it."

9. New Module Interface

24 Jul 2002 - 28 Jul 2002 (11 posts) Archive Link: "[PATCH][RFC] new module interface"

Topics: Kernel Build System

People: Roman ZippelRusty RussellKeith OwensKai Germaschewski

Roman Zippel announced:

The patch below is for 2.4 but it's easily ported to 2.5, beside of this I think the core is stable and will allow a more flexible module handling in the future. After updating to 2.5 and updating some more archs I will submit the patch officially, so any feedback now would be very welcome. (The patch requires no new modutils, although a new version could avoid some workarounds, but that can wait.)

This patch implements a new module interface. The most important change is probably that the usercount is not part of the module structure anymore. If the module code needs it, it asks the module for it. That count doesn't has to be accurate, only the return value of the exit functions decides about the unloading of the module. This also means no kernel structures have to be polluted with module pointers, the module structure is basically now private to the module code, no normal module needs to mess with it. This also means MOD_INC_USE_COUNT/MOD_DEC_USE_COUNT/MOD_IN_USE are now finally really obsolete. Modules have to maintain their own usecount, but this usually less painful than using a module pointer (see fs example below). In other situation such a count already exists, e.g. a proc like interface could use the i_count field of the inode (stop() unlinks the entry, exit() would test if i_count became 1). Below I converted affs and the fs code to demonstrate the new interface. So a module is defined like this:

        .start =        start_affs_fs,
        .stop =         stop_affs_fs,
        .exit =         exit_affs_fs,
        .usecount =     usecount_affs_fs,

This defines a structure, which is automatically registered at module init. A structure is more flexible than lots of function entries. insmod has to know about all these functions, where as above structure is automatically initialized when the module is linked. New fields can be added easily, e.g. new fixup sections can be added without bothering insmod.

On the other hand the old interfaces still work (even a direct init_module() call), it's just not possible to unload such modules.

One user visible difference is that /proc/modules now includes builtin modules. It requires a small kbuild change, as it needs unique module names. I'm not completely happy with this part yet, but it shows what is basically possible. More important is the difference between builtin modules and loaded modules becomes less.

Some more boring implementation details:

Rusty Russell asked what kernel the patch was against, and Roman said 2.4.18. They were both working in the same area, and discussed some implementation details. The discussion came round to the kbuild controvercy when Rusty remarked, "I need that too: the mythical "KBUILD_MODNAME". Both Keith and Kai promised it to me..." Keith Owens replied, "KBUILD_OBJECT has been in kbuild 2.5 since April 5 (kbuild-2.5-core-1). It is not my fault if Linus won't take it and Kai will not implement it." Meanwhile Kai Germaschewski also said to Rusty, "I told you that I have the code, and that I can provide it to you as soon as you need it. You did never ask for it, though. Do you need it now?" Rusty said that would be great, and Kai posted the code.

10. aic7xxx Developer Disconnect Over Hotplug Fixes

24 Jul 2002 - 25 Jul 2002 (10 posts) Archive Link: "[PATCH] aic7xxx driver doesn't release region"

Topics: Hot-Plugging, PCI, Power Management: ACPI

People: Justin T. GibbsJens Axboe

Takayoshi KOCHI posted a fix to the 2.4 and 2.5 aic7xxx driver, to allow the driver to release its memory and I/O regions. Without the patch, attempting to hotplug the device would fail. It had been tested on an IA32 server with ACPI PCI hotplug, and been reported to work. Justin T. Gibbs replied that this problem had already been fixed in the driver. He said, "I don't recall when exactly this was fixed in the aic7xxx driver, but probably 6.2.5 or so. The 2.5.X kernel must not be using a recent version of the driver. Marcelo's tree has 6.2.8 which definitely does not require this patch (won't even apply)." Takayoshi apologized for not examining the latest kernel pre-patches, but Jens Axboe chastized Justin, "You make it sounds as if someone would be updating it for you. The version that is in 2.5 is the version that you last updated it to, end of story." Justin Snapped back:

You make it sound like I have ever done any developement for 2.5. I haven't. Someone else did the port of the aic7xxx to 2.5. End of story. 8-)

Unfortunately, I haven't had any spare time to play with 2.5. I have faithfully maintained the 2.4 driver and will look at 2.5 once the time to do so presents itself.

Jens asked if Justin would mind if Jens went ahead and updated the 2.5 port, and Justin said, "Did you ask when you did the first port? 8-) In otherwords... be my guest." Jens thanked him, but added, "In all fairness, the first port _had_ to be done from my point of view since I needed _something_ to test the changes on. And to defend myself even further, I didn't have time to ask maintainers permission before Linus pulled the changes in. I can probably come up with a handful more reasons if needed :-)" Justin said, "This is opensource. Once the code goes out, I have limited control over what people do with it. This is by design and expected. There's no need to defend yourself since you didn't do anything wrong." To which Jens replied, "Well in theory you are right. But I always like to pass changes on to the maintainer for submission, and I expect others to do likewise. The maintainer usually has the better grasp of the code and can make the better call on what to include, reject, etc. Even though it's open source it doesn't have to be anarchy." End of thread.

11. 2.5.28 Released; Status Of IrDA, IDE, And SCSI; Development Philosophy

24 Jul 2002 - 29 Jul 2002 (94 posts) Archive Link: "Linux-2.5.28"

Topics: Disks: IDE, Disks: SCSI, Framebuffer, Kernel Release Announcement, PCI, SMP, USB, Version Control

People: Linus TorvaldsJean TourrilhesDaniel EggerBartlomiej ZolnierkiewiczAndries BrouwerJens AxboeAndries BrowuerDave JonesRob LandleyMatthew DharmJames BottomleyDoug LedfordAlessandro SuardiPaul LarsonMarcin Dalecki

Linus Torvalds announced 2.5.28, and said:

The most fundamental part of this has already been discussed a lot and posted to the kernel list, including a lot of fixes (all hopefully integrated). That's obviously the removal of the global irq lock. In the short term (famous last words) that breaks a number of SMP configurations, but fixing them should not be horribly hard.

A lot of other stuff here too - the regular USB updates, fbdev updates, m68k and ppc64 updates, IDE fix, and a sync-up with Al. Serial lawyer all shook up (the irq lock kind of forced that one, but it's certainly been pending long enough..)

Paul Larson reported trouble compiling that kernel, and Linus replied:

Yes, a number of drivers won't compile on SMP because they want the global lock (that is gone). This includes the cmd640 IDE driver, and the parallel port driver (and a largish number of others too, but I think those two are the really common ones).

It should all work the same way it always did on UP, and hopefully the straggling drivers will be converted to use local spinlocks soon (and in some cases the global irq lock might not even be needed at all)

Elsewhere, however, Alessandro Suardi reported trouble on his uniprocessor system, in the IrDA code. Jean Tourrilhes replied, "IrDA is not going to get fixed soon. Over the time I've been fixing the IrDA stack, I've slowly fixed some of most dangerous locking problems, but fixing the remaining code will involve some serious re-work and is unfortunately not just about sprinking a few spinlocks there and there." Linus replied to this:

Actually, the way to emulate cli/sti behaviour is not to "sprinkle" spinlocks, you can generally do it with _one_ spinlock per subsystem.

So the straightforward way to port away from cli/sti is to add one spinlock which takes their place for that subsystem, and then get that lock on entry to subsystem interrupts and timer events, and in all places where there used to be a cli/sti.

It gets a bit more complicated partly because you could nest cli/sti, and you can't nest spinlocks, but on the whole none of it is "rocket science".

Of course, doing it _right_ (rather than try to just translate the semantics of cli/sti fairly directly) can be a lot more work. But even a straight translation improves on what used to be, since different subsystems will now be independent, and since it is easier later on to split the one lock up on a as-needed basis.

But Jean replied that the one-spinlock approach wouldn't work for IrDA. He added, "here the problem is that the whole locking design is broken. I know perfectly that the hashbin locking is totally unsafe and it's a miracle that it work at all. And I'm not sure if I will ever get something 100% safe." There was a bit more discussion, but the sub-thread petered out inconclusively.

Elsewhere, Daniel Egger noticed that Linus' announcement only listed IDE as having been updated, but didn't list what the changes were. Linus said there had been plenty of disucssion on the list, "And since none of the discussion was civil, it didn't get a changelog. But you can search it out yourself." Daniel replied, "Especially since the IDE code at the moment is not really something I would trust uncoditionally a bit more comentary would be adequate IMHO, even if it's just a: "Fixed race introduced in IDE-97, see flamewar"..." Linus replied, "Most of the IDE stuff is FUD and misinformation. I've run every single 2.5.x kernel on an IDE system ("" has everything on IDE), and the main reported 2.5.27 corruption was actually from my BK tree apparently due to the IRQ handling changes." He added, "The thing I dislike is how people who apparently haven't even read the discussions, and didn't bother to look up the full changelog feel that they are perfectly fine to spread FUD and misinformation about the IDE layer. Do we have issues there? Yes. But there are actually _more_ problems with people dissing the work than with the code itself."

Bartlomiej Zolnierkiewicz said, "I wish it was misinformation." He added, "the thing I dislike is how people who apparently haven't read carefully every ide-clean patch, and didn't bother to look up the full track of changes (2.4 -> 2.5) feel that they are perfectly fine to make such statements ;-)." Daniel said to Linus, "I appreciate Martins work and even more your word on it that it's pretty stable. Keep on the good work and let us end this thread for good." But Andries Brouwer, also in reply to Linus, said:

Linus, Linus, how can you say something so naive? I need not tell you that one user without problems does not imply that nobody will have problems.

A few people reported lost filesystems. Many more reported mild filesystem damage. And now you also report mild filesystem damage.

FUD? Fear? Yes, the fear is justified for whoever does not have backups. Uncertainty? Yes, when the filesystem is damaged again, it is not quite clear what causes it. Doubt? Yes, many people doubt whether they can afford to run 2.5.recent.

This evening I ran vanilla 2.5.29 and was rewarded with mild filesystem damage. 91 files in /lost+found. Nothing. A few kernel versions ago it was three orders of magnitude worse.

IDE? 2.4.17 and 2.5.27+Jens are stable for me in ordinary use. IRQ? Quite possible. My third candidate is USB. Systems without USB are clearly more stable.

Linus said that he wasn't trying to say that nobody would have problems with IDE. He said, "there _are_ problems with IDE, but that the real problem with IDE is that some people aren't even willing to help despite the fact that we do have a maintainer that actually can work with people." He added, "I realize that so many people are probably used to the fact that IDE maintainers do not take patches from the outside that people have kind of given up on even working on IDE, but it doesn't help to have people only be negative (and btw, I'm definitely not talking about you - you've been exceedingly _positive_ in that you're still willing to test and report on problems. I'm talking about people who don't even bother to do bug-reports, but only trash-talk the maintenance)."

Linus went on to say that the filesystem damage people had reported had not been due to the IDE layer, even though IDE had been blamed for it. He went on:

And THAT is part of the problem. I don't know why, but the IDE subsystem brings out the worst in people.

This is, btw, one reason why I hate mid layers. People blame them for everything, and fixing it for one setup breaks it for another.

Elsewhere, Marcin Dalecki posted a SCSI patch, and Jens Axboe pointed out some problems. Marcin agreed, saying he'd just cut-and-pasted from other code, and Jens replied, "But the crap still got merged, sigh... Yet again an excellent point of why stuff like this should go through the maintainer. Apparently Linus blindly applies this stuff." Linus replied:

Ehh, since there is no proactive maintainer for SCSI, I don't have much choice, do I?

SCSI has been maintainerless for the last few years. Right now three people work on it to some degree (Doug Ledford, James Bottomley and you), but I don't get timely patches, and neither does apparently anybody else.

Case in point: I was debugging some USB storage issues with Matthew Dharm yesterday, and he sent me patches to the SCSI subsystem that he claims were supposedly considered valid on the scsi mailing list back in May.

Guess what? I've not seen the patches from any of the three people I consider closest to being maintainers.

So your "should go through the maintainer" complaint is obviously a bunch of bull. Feel free to step up to the plate, but before you do, don't throw rocks in glass houses.

Andries replied, "In the absence of a single active maintainer, peer review is a good alternative." And Linus replied:

I agree, but you still want to have somebody who actually steps up to the plate after the peer review has taken place, and sends me the patch..

And yes, if it's not one of the regular lieutenants, that does mean that me applying it will depend a bit more on just how much time I have. I would obviously prefer that the SCSI maintainer wouldn't necessarily sync directly with me, but with somebody I work with anyway - as long as it's reasonably timely.

(The _good_ news is that there haven't actually been all that many reasons to maintain SCSI for a while - most of the maintenance has actually been due to the generic block layer changes, which Jens has naturally been very good about. The rest has _mostly_ been about updating specific drivers to the PCI DMA interface (and various one-liners for the block layer changes).

He added, "Jens is actually documented as being the SCSI maintainer, but that is probably because he is the block device maintainer and he ended up maintaining the more fundamental changes. I've seen James Bottomley more as the "change SCSI internals" guy, and Doug mentioned that he will have more time to work on 2.5.x not that long ago, so I do think all three consider themselves at least partial maintainers already. I certainly take patches from all three." Dave Jones added:

*nods* Both Jens and Doug were invaluable at times when I bought forward a bunch of stuff from 2.4, (and later scooped up various other small SCSI bits from assorted places). With a lack of much understanding in this area, (and lack of motivation to dig too deeply -- I don't even own any SCSI hard disks/controllers except for some ancient cpqarray thats rarely powered on), pushing the various bits onto you with meaningful comments attached became quite hard work, and at times, impossible without further explanation from Jens or Doug.

Thankfully, Doug did an excellent job at weeding out the crap bits I had merged, and pushing on the good tried-n-tested bits.

So they both get my vote. James I think is actually doing some of the grunt work which means offloading the 'syncing/pushing to Linus' fun onto one of the others is probably a good idea if they're not opposed to doing it.

In Andries' same post, he said, "You killed the idea of maintainers yourself, proclaiming that you did not work with maintainers but with lieutenants." Rob Landley replied:

Linus didn't "kill the idea of maintainers", he just went to a four tier hierarchy for scalability reasons.

Here's my understanding of the current developent infrastructure. Anybody who wants to disagree with this feel free, otherwise there should probably be some kind of FAQ entry or update to Documentation/SubmittingChanges.

Developers submit to maintainers. Maintainers submit to lieutenants. Lieutenants submit to Linus. Each level can take stuff from anyone below them if they want to, but only the layer IMMEDIATELY below them is owed any sort of explanation as to why a patch was NOT accepted.

I.E. If anybody but a lieutenant submits a patch to Linus, and he drops it, there's not much likelihood of an explanation why. If a lieutenant signs off on a patch and forwards it to Linus, if it gets rejected he'll probably say why it was rejected. (It could be his mailbox runneth over, but there shouldn't be the "I submitted this a dozen times and never heard anything" problem when Lieutenants submit to Linus. In an ideal world, anyway. :)

This is, basically, what's special about lieutenants. They are the ONLY people to whom Linus owes any kind of explanation when a patch gets rejected. (The explanation may not be much more than "I don't like this, I'm not going to apply it, so there", but at least they aren't left hanging endlessly. At the very least it's closure.)

Similarly, lieutenants should reply to the maintainers who report to them when they reject patches the maintainer has signed off on. And maintainers should reply to individual developers who submit patches to them (by email; they may not see it if it's just posted on the list). These replies are not only common courtesy, they help the system work.

So if a random developer wants to get a patch to Linus, and Linus doesn't just snatch it out of the ether, the way to proceed is find the appropriate maintainer, and get their opinion of the patch. The developer needs to work with the maintainer until the patch is accepted by that maintainer: they need to fix anything the maintainer finds wrong with it, and if the maintainer says the whole thing is a bad idea, trying to "go over their heads" to a lieutenant is unlikely to work. (They have a wonderful excuse to ignore you, which is the least effort solution on their part. No you can't pester them into submission, you'll just wind up in an email auto-delete file.)

The maintainer may want changes, they may want peer review on a specific mailing list (sometimes linux-kernel, sometimes not), they may want benchmark results, they may want you to download and run a specific stress-testing suite... Or they may be happy with it as is, or they may just say "no" to the whole idea and you have to go try another approach entirely.

Then, once a developer has gotten the maintainer to sign off on a patch ("looks good to me"), the developer and/or the maintainer can submit it to the appropriate lieutenant, who is in charge of a larger part of the kernel and will most likely find a fresh batch of things wrong with the patch, so the process is repeated at the new level. (Knowing which lieutenant to forward developers with patches to is part of a maintainer's job.) When going for a lieutenant's blessing, it's still the developer's job to fix the patches. The maintainer was just passing judgement, now the lieutenant is. Neither is under any obligation to do your work for you. They find problems, but it's up to the developer to fix them. They may be enthused enough by your idea to take it and run with it, but there's no guarantee of this, and they usually have a to-do list as long as your arm (and that's in a very small font) well before your patch enters the picture.

Again, the lieutenant can veto the entire idea of your patch (the maintainer's approval does not mean their lieutenant will approve), or raise any number of objections. The lieutenant's approval is needed before proceeding, so the developer needs to fix anything the lieutenant finds wrong with the patch, regardless of what the maintainer thought.

Then once the lieutenant is appeased and signs off of it, the patch goes to Linus. The lieutenant should probably be the one to forward it (cc:ing the developer) or else Linus probably won't even notice it (his in-box runneth over).

Trivial, obvious bugfixes can sometimes bypass this using the trivial patch manager (something like, check the list archives. Rusty Russel runs it). Think of him as a "Lieutenant Jr. Grade", he accepts directly from developers, but only if it's a really obviously correct bug fix.

Bitkeeper helps this a bit: you can see when a patch goes in, so you get faster positive feedback. And once it's in somebody's bitkeeper tree it may trickle upward without too much more active push from the developers (until something is found to be wrong with it). But for negative feedback (that it was seen and rejected, and why) a developer still has to go through channels.

The advantage of all this is twofold:

  1. Developers aren't left hanging endlessly with nobody responding to their patch submissions. At each point, you know who to bug next to get an answer. (Maybe not the answer you want, but an answer.) This saves developers a lot of time and aggravation.
  2. By the time a patch get to Linus, it's already been reviewed by two competent developers (somebody he directly trusts and somebody else they trust), the obvious cleanups have been done, and if they thought it needed wider peer review they'll have already suggested it before giving their approval. (Some of them even run their own trees for testing purposes.) This saves Linus a lot of time and aggravation. (He will still reject a lot of these patches. Or require changes to be made, just like the first two levels.)

The reason some people think that maintainership is now meaningless is that Linus doesn't respond directly to maintainers. Because Linus appoints lieutenants, and the lieutenants appoint maintainers under them, Linus may never even have heard of some of the maintainers, let alone trust their judgement. But maintainers are needed to connect random unknown developers with lieutanants, so the lieutenants don't get overwhelmed. As long as the lieutenants listen to their maintainers, and Linus listens to his lieutenants, the system works fine.

There was no reply.

12. Port Of 'Strict VM Overcommit' To 2.5

24 Jul 2002 - 25 Jul 2002 (3 posts) Archive Link: "[PATCH] 2.5.28: VM strict overcommit"

Topics: Virtual Memory

People: Robert LoveAlan CoxHugh DickinsAndrew MortonLinus Torvalds

Robert Love submitted to Linus Torvalds and Andrew Morton:

Here again is a port of Alan's VM strict overcommit to the 2.5 kernel, with the new policy design Alan and I discussed.

This adds strict address-space accounting to enforce address-space limits and consequently never OOM. All memory failures should be pushed to the allocation routines.

Obviously overcommit is preferred for most so the default is the standard behavior. Strict overcommit is controllable via sysctl. See the included documentation.

I would like to get this into 2.5 to see more testing and provide a base for some of the shmem / overcommit fixes Hugh Dickins as been working on. In the default configuration, behavior should be unchanged.

Patch is against 2.5.28, please apply.

Andrew had some problems with the patch, but Alan Cox felt the patch was ready. The thread ended inconclusively.

13. Header Files And The Kernel Application Binary Interface

24 Jul 2002 - 31 Jul 2002 (18 posts) Archive Link: "Header files and the kernel ABI"

Topics: FS: initramfs, FS: ramfs, Klibc

People: H. Peter AnvinBrad Hards

H. Peter Anvin proposed:

I have had a thought grinding in my head for a while, and wanted to throw it out for everyone to think about...

In the libc4/libc5 days, we attempted to use kernel headers in user space. This was a total mess, not the least because the kernel headers tended to pull in a lot of other kernel headers, and the datatypes were unsuitable to have spead all across userspace.

In glibc, the official rule is "don't use kernel headers." This causes problems, because certain aspects of the kernel ABI is only available through the include files, and reproducing them by hand is tedious and error-prone.

I'm in the process of writing a very tiny libc for initramfs, and will likely have to deal with how to use the kernel ABI as well.

It seems to me that a reasonable solution for how to do this is not for user space to use kernel headers, but for user space and the kernel to share a set of common ABI description files[1]. These files should be highly stylized, and only describe things visible to user space. Furthermore, if they introduce types, they should use the already-established __kernel_ namespace, and of course __s* and __u* could be used for specific types.

This means that we would be able to get rid of #if(n)def __KERNEL__ in the main kernel header files, because there would be a separation by file location -- something in the main kernel include files could include the ABI description files, but the opposite should never be true.

I would like to propose that these files be set up in the #include namespace as <linux/abi/*>, with <linux/abi/arch/*> for any architecture-specific support files (I do believe, however, that those files should only be included by files in the linux/abi/ root. This probably would be a symlink to ../asm/abi in the kernel sources, unless we change the kernel include layout.) The linux/ namespace is universally reserved for the kernel, and unlike <abi/*> I don't know of any potential conflicts. I was considered <kabi/*>, but it seems cleaner to use existing namespace.

If people think this is an idea, I will try to set up the infrastructure as part of my work on klibc, although I'm definitely not going to be able to migrate every portion of every include file that needs to be migrated all by myself.

There was a lot of initial enthusiasm for this idea, but a few days later Brad Hards said:

Well the initial enthusiasm appears to have passed, and nothing is happening.

Is there interest in getting together to resolve this issue?

I note that the next major conference appears to be Linux Kongress (Koln/Cologne) in early September. Maybe we can get some glibc / other-libraries people there, and make some progress.

If there is some interest (post off-list if preferred), I'll contact the organisers and try to get a BoF together for this.

I'll look at as an additional opportunity when time gets a bit closer.

There was no reply.

14. LVM Update For 2.4

25 Jul 2002 - 26 Jul 2002 (8 posts) Archive Link: "LVM 1.0.5 patch for Linux 2.4.19-rc3"

Topics: Disk Arrays: LVM, Ioctls, SMP

People: Heinz MauelshagenChristoph Hellwig

Heinz Mauelshagen announced:

have send an LVM 1.0.5 patch to Marcelo directly which addresses:

It is available at: <>

Christoph Hellwig asked, "Any estimate when Stephen's non-broken pvmove implementaion will be merged?" And Heinz replied, "Probably next month" [August] "if I get time for that."

15. Generic RTC Driver

25 Jul 2002 (1 post) Archive Link: "[PATCH] A generic RTC driver [0/3]"

Topics: Real-Time, SMP, Version Control

People: Tom RiniPaul MackerrasGeert Uytterhoeven

Tom Rini posted code to implement a generic real-time clock (RTC) driver, and explained:

This is essentially the same driver I've sent 3 time previously, except it's been broken down into 3 patches now, and it works on i386 (and should work on alpha) now.

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

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.

Based on some private feedback, the parisc-linux people have been using the 2.4 version of this driver for a while, so getting it to work on 2.5 for them should be a trivial matter (it's currently in their tree, untested as other issues need to be resolved first). 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.

16. Thread-Local Storage For 2.5

25 Jul 2002 - 28 Jul 2002 (9 posts) Archive Link: "[announce, patch] Thread-Local Storage (TLS) support for Linux, 2.5.28"

Topics: SMP

People: Ingo MolnarOleg Nesterov

Ingo Molnar implemented a new system call, sys_set_thread_area(), to provide x86 TLS (Thread Local Storage) support, a fast and efficient way to store per-thread local data. He described:

proper TLS support in compilers (and glibc/pthreads) is a bit problematic on the x86 platform. There's only 8 general purpose registers available, so on x86 we have to use segments to access the TLS. The approach used by glibc so far was to set up a per-thread LDT entry to describe the TLS. Besides the generic unrobustness of LDTs, this also introduced a limit: the maximum number of LDT entries is 8192, so the maximum number of threads per application is 8192.

this patch does it differently - the kernel keeps a specific per-thread GDT entry that can be set up and modified by each thread:

asmlinkage int sys_set_thread_area(unsigned int base, unsigned int limit, unsigned int flags)

the kernel, upon context-switch, modifies this GDT entry to match that of the thread's TLS setting. This way user-space threaded code can access per-thread data via this descriptor - by using the same, constant %gs (or %gs) selector. The number of TLS areas is unlimited, and there is no additional allocation overhead associated with TLS support.

the biggest problem preventing the introduction of this concept was Linux's global shared GDT on SMP systems. The patch fixes this by implementing a per-CPU GDT, which is also a nice context-switch speedup, 2-task lat_ctx context-switching got faster by about 5% on a dual Celeron testbox. [ Could it be that a shared GDT is fundamentally suboptimal on SMP? perhaps updating the 'accessed' bit in the DS/CS descriptors causes some sort locked memory cycle overhead? ]

the GDT layout got simplified:

* 0 - null
* 1 - Thread-Local Storage (TLS) segment
* 2 - kernel code segment
* 3 - kernel data segment
* 4 - user code segment <==== new cacheline
* 5 - user data segment
* 6 - TSS
* 7 - LDT
* 8 - APM BIOS support <==== new cacheline
* 9 - APM BIOS support
* 10 - APM BIOS support
* 11 - APM BIOS support
* 12 - PNPBIOS support <==== new cacheline
* 13 - PNPBIOS support
* 14 - PNPBIOS support
* 15 - PNPBIOS support
* 16 - PNPBIOS support <==== new cacheline
* 17 - not used
* 18 - not used
* 19 - not used

set_thread_area() currently recognizes the following flags:

#define TLS_FLAG_LIMIT_IN_PAGES 0x00000001
#define TLS_FLAG_WRITABLE 0x00000002
#define TLS_FLAG_CLEAR 0x00000004

(the system-call does not expose any other segment options to user-space, priviledge level is 3, the segment is 32-bit, etc. - it's using safe and sane defaults.)

NOTE: the interface does not allow the changing of the TLS of another thread on purpose - that would just complicate the interface (and implementation) unnecesserily. Is there any good reason to allow the setting of another thread's TLS?

NOTE2: non-pthreads glibc applications can call set_thread_area() to set up a GDT entry just below the end of stack. We could use some sort of default TLS area as well, but that would hard-code a given segment.

i fixed a number of unclean items in our GDT/IDT handling as well:

the patch compiles, boots & works just fine on UP and SMP x86 boxes. Comments and suggestions are welcome,

Oleg Nesterov had some nits to pick with the patch, and they hashed them out together for a little while. No major changes were introduced.

17. User-Mode-Linux 2.5.28 Released

25 Jul 2002 (1 post) Archive Link: "UML 2.5.28"

Topics: Disks: SCSI, User-Mode Linux

People: Jeff Dike

Jeff Dike announced:

UML has been updated to 2.5.28 and UML 2.4.18-44. The changes since 2.5.27 include:

Since UML didn't make 2.5.27, 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.

18. Help Sought For Linux Weekly News

26 Jul 2002 - 27 Jul 2002 (7 posts) Archive Link: "Linux Weekly News dying - any help?"

People: Bert HubertDaniel PhillipsRik van RielRussell KingJohn Bradford

Bert Hubert was distressed to learn that Linux Weekly News was closing down. He said, "We bought some advertising on LWN but can of course not keep them alive ourselves. Does anybody here have ideas on how to keep them in business? See" John Bradford said he'd be happy to contribute to the site as a volunteer if someone would host the domain. Russell King said he felt sure someone would be willing to donate space on a server, but Daniel Phillips replied, "Jon points out that salaries are the problem. There seems to be a shortfall of $150,000, or perhaps a little more, in that department." Bert also said to Russell:

It is not the server. I have a server for them. I think many do not realise how much time Jon & friends spend on making LWN, and it is precisely this *time* that sets them apart from everything else.

Compare them to a Linux dedicated - real journalism with analyses that go beyond what is provided by CmdrTaco (entertaining though he may be) and their like.

In order to make LWN, they need to find a way to give them the time to work on it. They can't do it next to a day job.

And Rik van Riel added:

Absolutely. You cannot do a news site of LWN quality with 100 volunteers that all spend 2 hours a week getting informed.

Instead, you need a few people that are really well informed. This costs money, because these people won't have time to do other things that pay their bills.

I'm donating some money right now. If it doesn't save them for a bit more time I'll just consider it overdue subscription fees and a thank you...

19. Support For SiS IDE ATA 133 In 2.4 Kernels

26 Jul 2002 - 27 Jul 2002 (4 posts) Archive Link: "[PATCH] SiS IDE ATA 133 support"

Topics: Disks: IDE

People: Lionel BoutonDaniel Egger

Lionel Bouton announced that Lui-Chen Chang from SiS had implemented ATA133 support for SiS IDE chipsets. He posted the original patch against 2.4.19-rc3, and his own version against 2.4.19-rc3-ac3. In a later post, he added, "the rc3-ac3 patch is already running on my ECS K7S5A and the rc3 patch has been tested on 961 and 962 southbridges by Lei-Chun." He asked for other folks to test the code, and Daniel Egger said he would.

20. Supporting Many SCSI Disks In 2.4 And 2.5

26 Jul 2002 - 27 Jul 2002 (9 posts) Archive Link: "[PATCH] sd_many done right (1/5)"

Topics: Disk Arrays: EVMS, Disk Arrays: LVM, Disk Arrays: RAID, Disks: IDE, Disks: SCSI, FS: driverfs

People: Kurt GarloffAndreas DilgerChristoph HellwigAlexander Viro

Kurt Garloff posted some patches for 2.4, to support more than 128 SCSI disks by default, and optionally more than 256. The driver handled this by dynamically allocating resources as each disk was attached to the system. He gave a link and said that the patch "does implement some infrastructure that is useful: We extend the format of /proc/scsi/scsi to report the attached high-level drivers. This can be used by userspace applications to dynamically create device nodes or to talk to the corresponding sg device (which otherwise is non- trivial to find out!) and inquire extra information such as serial number or WWID."

Alexander Viro looked at the patch and found that although it might work for 2.4, it would never get into 2.5 in the same form. Kurt replied, "The sd parts can and should be ported to 2.5, I think. The /proc/scsi/scsi extensions and other stuff I wrote to support it, won't be needed, as we have driverfs in 2.5. And, of course, the device number management will be solved in a more general way, but I do not yet see how." Andreas Dilger replied:

Actually, one interesting aspect of the EVMS vs. device-mapper argument going on that has totally been missed is that EVMS can do management of ALL disk block devices.

At startup time it "consumes" all of the disk block devices in order to generate the various mappings (LVM, RAID, etc) and at the end it spits out the resulting devices as EVMS major devices. This includes devices that have not been remapped, like hdXY or sdMN. EVMS has facilities to ensure that devices get repeatable major/minor numbers if needed, but they are allocated on an as-needed basis.

Currently EVMS only has a single major number, but it is my understanding that they could easily take over all of the IDE and SCSI major numbers. We would not have to worry about sparse device number allocation anymore, and could have thousands of disks/partitions without any problems.

Christoph Hellwig said that of course EVMS did management of all disk block devices, because it attempted to duplicate the Linux block layer. "But it's everything but a good idea," he said. Kurt replied that he didn't want to get into an EVMS versus block layer debate since he didn't know whether EVMS did what Christoph claimed; but he did say, "But the idea of having a number of majors assigned to disks, no matter what the driver below is looks certainly like a good idea. With the current approach, we'll need way too many majors, even if we'd have some more bits in the future. Why not have a pool of disk majors and sd, hd, dasd, rd (DAC960), the IDE-Raids, and ... allocate some of these as needed." Christoph replied:

Linus wants this, and he stated that again on the kernel summit. But to do this porperly (= not the EVMS way) it needs preparation. Al currently does lots of work in that area to make the block drivers largely independent of the major number. Once the drivers don't need the major number anymore internally the only that needs sorting out is userlevel backwards-compatinlity.

I'm pretty sure the preparation will be finished for 2.6, also I can't comment whether the unified disk major will be done.

21. devfs Update

28 Jul 2002 (1 post) Archive Link: "[PATCH] devfs v215 available"

Topics: FS: devfs

People: Richard Gooch

Richard Gooch announced:

Version 215 of my devfs patch is now available from:

The devfs FAQ is also available here.

Patch directly available from:


NOTE: kernel 2.5.1 and later require devfsd-v1.3.19 or later.

This is against 2.5.28. Highlights of this release:

There was no reply.

22. New PC-Speaker Driver

29 Jul 2002 (1 post) Archive Link: "[ANNOUNCE] New PC-Speaker driver"

Topics: Sound: OSS

People: Stas SergeevDavid Woodhouse

Stas Sergeev announced:

For all those people who still don't have a sound card I want to introduce a pc-speaker driver. There were some other pc-speaker drivers floating over the net, but AFAIK no one is really finished and usable.

My driver is originally based on Michael Beck and David Woodhouse driver, but it is havily reworked and pretends to be 100% OSS compatible producing nearly the best sound one can ever get from pc-speaker. Well, there is (currently) no intention to get it into the mainstream kernel so don't treat it too seriously. However any comments or bugreports are appreciated.

The latest patch for 2.4.18 kernel is available here:

There was no reply.

23. Status Of /proc/pci

29 Jul 2002 - 31 Jul 2002 (7 posts) Archive Link: "RFC: /proc/pci removal?"

Topics: PCI

People: Russell KingDave JonesMartin Mares

Russell King asked, "I seem to vaguely remember that a while ago (2.3 days?) there was discussion about removing /proc/pci in favour of the lspci output, however there doesn't seem much in google groups about it (and marc seems useless with non-alphanumeric searches.) Can anyone remember the consensus?" Dave Jones remarked, "ISTR Linus was quite attached to it, so it got un-obsoleted." And Martin Mares added:

Exactly. I've marked it as obsolete years ago, but when I wanted to rip it out, Linus said he likes /proc/pci and it has to stay.

I still think that it's an extremely ugly interface, especially because it requires the kernel to contain the list of vendor and device names.

24. HP Diva Support For 2.5.29

29 Jul 2002 (1 post) Archive Link: "[PATCH] 2.5.29 serial update"

People: Matthew WilcoxRussell King

Russell King announced a new batch of serial driver changes to 2.5.29. The main feature was to add HP Diva support by Matthew Wilcox. There was no reply.

25. 64-Bit PowerPC Maintainership

29 Jul 2002 - 30 Jul 2002 (3 posts) Archive Link: "[TRIVIAL] Anton Blanchard is 2.5 PPC64 maintainer"


People: Rusty RussellTodd InglettTom GallAnton Blanchard

Rusty Russell posted a trivial patch to the MAINTAINERS file, to list Anton Blanchard as the 64-bit PowerPC port maintainer for 2.5 kernels instead of David Engebretsen. He said, "Anton is the one all the mail goes to, and who sends the patches to Linus. David is the 2.4 maintainer." Todd Inglett replied:

I think you ought to clear this with Dave. He's been swamped with 2.4 work, but I don't think he has ever planned to give up maintainership just because this is 2.5.

There's no denying that Anton's been doing lots of work keeping 2.5 ppc64 up-to-date but that doesn't automatically mean maintainership should swap.

And Tom Gall also said to Rusty, "Dave continues to be the overall maintainer for ppc64. See"

26. Sparc32 Maintainership

29 Jul 2002 (1 post) Archive Link: "[TRIVIAL] Mark sparc32 unmaintained in 2.5"

People: Rusty Russell

Rusty Russell, after checking with David Miller, posted a patch to list the Sparc32 port as unmaintained in 2.5. There was no reply.

27. BitKeeper Documentation

30 Jul 2002 - 31 Jul 2002 (5 posts) Archive Link: "Simple BK HOWTO"

Topics: Ottawa Linux Symposium, Version Control

People: Dave JonesVal Henson

Krzysiek Taraszka asked for some simple BitKeeper documentation, and some folks pointed him to Documentation/BK-usage; Dave Jones added:

The BK test drive is useful -

See also the slides etc from the talk Val Henson gave at OLS on her page -

28. Modutils 2.4.19 Available

31 Jul 2002 (1 post) Subject: "Announce: modutils 2.4.19 is available"

People: Keith OwensRichard HirstBill Nottingham

Keith Owens announced modutile 2.4.19, and said:

Changelog extract

IA64 users who debug modules are strongly urged to upgrade to this release.

There was no reply.

29. Status Of -dj Tree

31 Jul 2002 (1 post) Subject: "why no new 2.5-dj patch ?"

Topics: Version Control

People: Dave Jones

Dave Jones said:

I'm fed up of answering the same questions over and over, so I figured I'd post this here.

Most common question I'm getting right now seems to be summed up as "Why haven't I done a 2.5-dj since .27 ?" (Yup, a whole 2 point releases, and people are breaking into a sweat)

The last point marks an important change in the way I've been working up until now. I spent a while trying to figure out how to take a holiday, and not have to come back to a nightmare resync. FSF purists will hate me for it, but I've started playing with BitKeeper again, and it's working out. (The curious can look around at

I've put off pushing bits to Linus this week to deliberatly make life more difficult for myself syncing his latest tree with mine, to see if bk really will work out. So far what usually takes me the better part of an hour I can now do in 10 minutes.

So when I come back, resyncing should be a lot less painful than it used to be, and I'll start looking at pushing some of the bits that have been hanging around for a while towards Linus.

One final point: Due to me being away for a week, I won't be merging anything new to my tree 8) Feel free to still send it, and I'll pick it up when I return.

There was no reply.

30. 2.4.19-rc4 Released

31 Jul 2002 (2 posts) Subject: "Linux 2.4.19-rc4"

Topics: SMP

People: Marcelo Tosatti

Marcelo Tosatti put out 2.4.19-pre4 and said, "Since some critical problems appeared (mainly the d_unhash() SMP race) here is rc4." Rudmer van Dijk reported some warning during compilation, but there was no further discussion.

31. Stream Control Transmission Protocol Update

31 Jul 2002 (1 post) Subject: "[ANNOUNCE] new lksctp release lksctp-2_5_29-0_5_0"

People: Jon Grimm

Jon Grimm announced:

Linux Kernel SCTP Release lksctp-2_5_29-0_5_0 is now available for download.

The lksctp project was created to develop a Linux kernel implementation of the SCTP transport protocol.

For more information, as well as, source tarballs and patches, please visit:

The linux-2.5.29 based patch can be downloaded directly from:

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.