Kernel Traffic #178 For 4 Aug 2002

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

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.

register_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:

• the probe-event handler address, which is called as the probed instruction is about to execute. On return kprobes will single-step the probed instruction;
• the post-execution handler address, which is called when single-stepping completes
• the fault handler address, which is called if an exception is generated for any instruction within the fault-handler or when kprobes single-steps the probed instruction.

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;
};

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

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

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

fault_handler:
the function that will be called if any software exceptions occur

• while executing inside the probe_handler
• when single-stepping the probed instruction

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:

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.

http://oss.software.ibm.com/developerworks/opensource/linux/projects/dprobes/

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.

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.

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

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:

• I'm NOT going to track the various typos, thinkos, and minor syntax errors. I'm aiming more for things such as the IDE problem, the broken flock, and odd memory corruption problems which entail more extended discussion than a simple one-line code fix. It's going to be more of a judgement call as to what is included and what isn't.
• In the extended discussions I plan on omitting various bits I consider flamage not pertinent to the subject. If anyone has a gripe with my editing, please contact me off-list.
• I received some feedback saying that I ought to merely point at archived threads for fixes, etc. I considered that, but it seems that an edited discussion might be more useful. This is especially evident in cases where the flow of messages go from point to point. In this case editing out headers and superfluous attributions makes it look better to my eyes.
• It was also suggested that I'm merely duplicating existing TODO lists and other material. Maybe. One thing it has done was make me think more than superficially about some issues I hadn't paid attention to before.
• To keep the list "clean" I plan on archiving previously fixed issues, only brining forward to a new kernel release report those issues which haven't been "closed." An item's status can be open (discussion continues, no generally agreed upon solution available), proposed fix (a patch is available and is being tested and discussed), tested fix (generally agreed upon and in a major maintaners -- aa,ac,dj -- patchset and ready for merging), and closed when it is integrated into the next Linus-blessed version.

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:

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

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:

• get_kernel_syms syscall is gone, it's not needed by modutils anymore, only klogd is still using it, but it can live without it and should rather be updated.
• new macros mod_for_each_locked/mod_for_done_locked to iterate over the modules list
• __MODULE_STRING is replaced with __stringify
• BKL is replaced with a semaphore
• get_mod_name/put_mod_name is replaced with getname/putname

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.

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

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)

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.

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.

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.

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.

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

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

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 trivial@rustcorp.com, 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.

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.

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.

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 linux.conf.au as an additional opportunity when time gets a bit closer.

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

• an OBO error accessing the vg array
• SMP lock fixes
• using blk_ioctl()
• indenting

It is available at: <http://people.sistina.com/~mauelshagen/lvm_patches/lvm_1.0.5+_25.07.2002.patch>

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.

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

• in theory we could avoid the 'limit in pages' bit, but i wanted to preserve the flexibility to potentially enable the setting of byte-granularity stack segments for example. And unlimited segments (granularity = pages, limit = 0xfffff) might have a performance advantage on some CPUs. We could also automatically figure out the best possible granularity for a given limit - but i wanted to avoid this kind of guesswork. Some CPUs might have a plus for page-limit segments - who knows.
• The 'writable' flag is straightforward and could be useful to some applications.
• The 'clear' flag clears the TLS. [note that a base 0 limit 0 TLS is in fact legal, it's a single-byte segment at address 0.]

(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 'gdt' pointer is completely unnecessery, it introduces an additional redirection.
• ditto the 'idt' pointer.
• this also enabled simpler setting of the GDT/IDT descriptors.
• on UP the GDT got smaller in fact, by a few bytes :-)
• cleaned up LDT loading: load_LDT_desc() now loads the (constant) LDT selector. A pity that we have to do this - but it's necessery to flush the LDT shadow descriptors.
• the thread context-switching hotpath included a call to a non-inlined function - set_ldt_desc() - this function is inlined now.

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

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

• A config reorganization and Makefile cleanups
• UML processes can pass notifications to mconsole clients via /proc/mconsole
• SCSI now works. The only low-level drivers available right now is the in-memory scsi_debug driver.
• A batch of honeypot bugs were fixed
• I fixed some problems with hostfs, but it still doesn't work.

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

The patch is available at
http://uml-pub.ists.dartmouth.edu/uml/uml-patch-2.5.28-1.bz2

For the other UML mirrors and other downloads, see
http://user-mode-linux.sourceforge.net/dl-sf.html

Other links of interest:
The UML project home page : http://user-mode-linux.sourceforge.net
The UML Community site : http://usermodelinux.org

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 Theregister.co.uk - 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.

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

http://old.lwn.net/corp/donate/

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.

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.

Version 215 of my devfs patch is now available from:

http://www.atnf.csiro.au/~rgooch/linux/kernel-patches.html

The devfs FAQ is also available here.

Patch directly available from:

ftp://ftp.us.kernel.org/pub/linux/kernel/people/rgooch/v2.5/devfs-patch-current.gz

AND:

ftp://ftp.atnf.csiro.au/pub/people/rgooch/linux/kernel-patches/v2.5/devfs-patch-current.gz

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

This is against 2.5.28. Highlights of this release:

• Created <devfs_find_and_unregister>
• Switched many functions from <devfs_find_handle> to <devfs_find_and_unregister>
• Switched many functions from <devfs_find_handle> to <devfs_get_handle>

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:

http://www.geocities.com/stssppnn/pcsp.html

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.

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.

The BK test drive is useful - http://www.bitkeeper.com/Test.html

See also the slides etc from the talk Val Henson gave at OLS on her page - http://www.nmt.edu/~val/

Changelog extract

• Correct ia64 SEGREL relocations. Fixes incorrect unwind data for ia64 modules.
• Remove 64 bit warnings.
• New aliases. Bill Nottingham.
• Add R_PARISC_PCREL22F. Richard Hirst.
• Remove flex warning.

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

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)

• Due to the huge driver breakage during .28/.29/.30tobe, Compilation issues aside, I've not had much luck in even getting the last few kernels to boot on most of my test boxes. If I don't get a 2.5-dj booting on all my test boxes, I won't make it available.
• Lack of time. I've been busy with x86-64, and other projects.
• Vacation. As of Friday, I'm taking time out for a real holiday for the whole week for the first time in a year. Ie, no net connection.

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 http://linux-dj.bkbits.net)

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.

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:

http://www.sourceforge.net/projects/lksctp/

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

http://prdownloads.sourceforge.net/lksctp/lksctp-2_5_29-0_5_0.patch?download