Kernel Traffic #329 For 26 Sep 2005

By Zack Brown

Table Of Contents

Mailing List Stats For This Week

We looked at 2114 posts in 13MB. See the Full Statistics.

There were 694 different contributors. 278 posted more than once. The average length of each message was 105 lines.

The top posters of the week were: The top subjects of the week were:
67 posts in 317KB by andrew morton
66 posts in 814KB by
46 posts in 191KB by al viro
45 posts in 285KB by nick piggin
44 posts in 208KB by blaisorblade
55 posts in 264KB for "[patch] support utf-8 scripts"
49 posts in 197KB for "p = kmalloc(sizeof(*p), )"
44 posts in 222KB for ""read my lips: no more merges" - aka linux 2.6.14-rc1"
42 posts in 274KB for "automatic configuration of a kernel"
37 posts in 161KB for "[rfc] splitting out kernel<=>userspace abi headers"

These stats generated by mboxstats version 2.8

1. Using linux/irq.h Or asm/irq.h In Drivers

9 Sep 2005 - 15 Sep 2005 (5 posts) Archive Link: "[RFC] killing linux/irq.h"

People: Alexander ViroGeert UytterhoevenMatthew WilcoxChristoph Hellwig

Alexander Viro said:

We get regular portability bugs when somebody decides to include linux/irq.h into a driver instead of asm/irq.h. It's almost always a wrong thing to do and, in fact, causes immediate breakage on e.g. arm.

Here's what I'm going to do:

Objections? That variant leaves out-of-tree folks with window until 2.6.15 to convert and that's really more than enough...

But Geert Uytterhoeven suggested, "Wouldn't it be more logical to make linux/irq.h the preferred include? Usually the linux/* versions are preferred over the asm/* versions." Matthew Wilcox replied, "There's almost no reason to want <*/irq.h> in the first place. Almost all drivers really want <linux/interrupt.h>" But Christoph Hellwig pointed out, "<linux/interrupt.h> doesn't include <asm/irq.h> and variours achitectures have important prototypes in there." The thread ended here, with not clear determination to prefer linux/irq.h or asm/irq.h.

2. Linux 2.6.13-mm3 Released

12 Sep 2005 - 18 Sep 2005 (55 posts) Archive Link: "2.6.13-mm3"

Topics: Kernel Release Announcement, Profiling

People: Andrew Morton

Andrew Morton announced Linux 2.6.13-mm3, saying:

(temp copy at

3. Linux 2.6.14-rc1 Released

12 Sep 2005 - 16 Sep 2005 (56 posts) Archive Link: ""Read my lips: no more merges" - aka Linux 2.6.14-rc1"

Topics: Bug Tracking, Digital Video Broadcasting, I2C, Kernel Release Announcement, PCI, Power Management: ACPI

People: Linus TorvaldsPeter OsterlundChuck Ebbert

Linus Torvalds announced Linux 2.6.14-rc1, saying:

Ok, it's been two weeks (actually, two weeks and one day) since 2.6.13, and that means that the merge window is closed. I've released a 2.6.14-rc1, and we're now all supposed to help just clean up and fix everything, and aim for a really solid 2.6.14 release.

Both the diffstat and the shortlog are so big that I can't post them on the kernel mailing list without getting the email killed by the size restrictions, so there's not a lot to say.

alpha, arm, x86, x86-64, ppc, ia64, mips, sparc, um.. Pretty much every architecture got some updates. And an absolutely _huge_ ACPI diff, largely because of some re-indentation.

drm, watchdog, hwmon, i2c, infiniband, input layer, md, dvb, v4l, network, pci, pcmcia, scsi, usb and sound driver updates. People may appreciate that the most common wireless network drivers got merged - centrino support is now in the standard kernel.

On the filesystem level, FUSE got merged, and ntfs and xfs got updated. In the core VFS layer, the "struct files" thing is now handled with RCU and has less expensive locking.

And networking changes.

In other words, a lot of stuff all over the place. Be nice now, and follow the rules: put away the new toys, and instead work on making sure the stuff that got merged is all solid. Ok?

Anybody with git can do the shortlog with

git-rev-list --no-merges --pretty=short v2.6.14-rc1 ^v2.6.13 | git-shortlog | less -S

which is actually pretty informative.

Peter Osterlund replied:

My Compaq Presario R3057EA hangs during ACPI initialization. The last message is "Executing all Device _STA and _INI methods". git bisect told me that:

  66759a01adbfe8828dd063e32cf5ed3f46696181 is first bad commit
  diff-tree 66759a01adbfe8828dd063e32cf5ed3f46696181 (from 049cdefe19f95b67b06b70915cd8e4ae7173337a)
  Author: Chuck Ebbert <>
  Date:   Mon Sep 12 18:49:25 2005 +0200

[PATCH] x86-64: i386/x86-64: Fix time going twice as fast problem on ATI Xpress chipsets

Original patch from Bertro Simul

This is probably still not quite correct, but seems to be the best solution so far.

Signed-off-by: Linus Torvalds <>

Linus replied, "Ok. That patch has been one big pain, and was clearly totally half-baked. I think I'll disable the automated checks, since they are clearly wrong. You can still enable it manually with a kernel command line." He posted a patch, and Peter said this fixed it for him. In his own defense, Chuck Ebbert said:

Well I never meant it to be merged, but Andi picked it up from Bugzilla bug #3927, added some bugs of his own, then sent it on.

This bug was mine, though: just checking for vendor == ATI was a bad idea. Current earlyquirk code actually looks at PCI bridges instead of host bridge, so to get an accurate test I guess it needs to look at PCI dev 00:00.0 and check both vendor and device ID. As new models come out they will have to be added one by one.

With a real understanding of what's going on maybe this problem can be solved reliably with generic code, but it's beyond me...

4. Framework For Automatic Kernel Configuration

14 Sep 2005 - 17 Sep 2005 (42 posts) Archive Link: "Automatic Configuration of a Kernel"

People: Ahmad Reza CheraghiHua ZhongRoman Zippel

Ahmad Reza Cheraghi said:

I wrote this Framework for making a .config based on the System Hardwares. It would be a great help if some people would give me their opinion about it.

The readme:

The Kernel Patch: (

The sources:

A lot of folks liked this work. As Hua Zhong put it, "There seems to be a trend that discourages normal users from running kernels, but I rarely find myself agree with such mind set." But Roman Zippel was skeptical that Ahmad (or anyone) would have the wherewithal to finish the project. He felt the work involved would be huge, but Ahmad and others felt it would be possible to bypass a lot of the difficulties. At one point elsewhere, Ahmad also said:

I want to tell why I came to this Idea of doing that. As I was trying to configurate a Kernel for the first time but without any success. Then I thought about it, why this cannot be automatically.

So for the first thought, my spirit of doing this, was for those who doesn't know e.g. what the option "Enable loadable module support" means and if they have to choose that or not. But right now I know that it is not possible to do all the things automatically(like the filesystem, Protokolls...). And that is the reason why I make a Framework, so everybody(I mean the experts) can give theire suggestion what isthe best way to answering, a optione like mention above comes, automatically. So if someone wants to use a new kernel didn't end up desperate and regrated using Linux(a new Kernel).

5. Review Cycle Starts For Linux

14 Sep 2005 - 15 Sep 2005 (20 posts) Archive Link: "[PATCH 00/11] -stable review"

Topics: FS: JFS, Ioctls, PCI, SMP, Security

People: Chris WrightMartin MaresDavid LangAndrew MortonAlexander NybergManfred SpraulIngo MolnarMarc LehmannLinus TorvaldsDave KleikampChuck EbbertPatrick McHardyRoland McGrathJeff GarzikAndi KleenAndre HedrickAdam Kropelin

Chris Wright announced the start of the review process leading up to, saying:

There are 11 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let us know. If anyone is a maintainer of the proper subsystem, and wants to add a signed-off-by: line to the patch, please respond with it.

These patches are sent out with a number of different people on the Cc: line. If you wish to be a reviewer, please email to add your name to the list. If you want to be off the reviewer list, also email us.

Responses should be made by Sat Sep 17 01:00 2005 UTC. Anything received after that time, might be too late.

He replied to this with a series of patches, whose changelogs follow:

That last one had some discussion. Martin Mares said, "Once upon a time when I was the PCI maintainer, I was arguing with Andre Hedrick about this one and he kept asserting that enabling the ROM is necessary to make the chip work. Not that I believe it :)" There was no reply to this, but close by, David Lang said, "didn't Linus find similar bugs in a couple of the other hpt drivers as well? if so can they be fixed at the same time?" Andrew Morton confirmed, "Adam Kropelin did a sweep and picked up four similar cases. I queued the patches and they should be considered for" But Chris said these fixes were already part of the patch.

Elsewhere, Alexander Nyberg suggested adding another patch to the stable review series. He said:

This might be worth putting in too (has been hit by at least two people in the real world etc.)

tree e3a704026e65bf6fea0c7747f0fb75a506f54127
parent 32a3658533c6f4c6bf370dd730213e802464ef9b
author Alexander Nyberg <> Wed, 14 Sep 2005 18:54:06 +0200
committer Linus Torvalds <> Thu, 15 Sep 2005 00:26:34 -0700

[PATCH] Fix fs/exec.c:788 (de_thread()) BUG_ON

It turns out that the BUG_ON() in fs/exec.c: de_thread() is unreliable and can trigger due to the test itself being racy.

de_thread() does

        while (atomic_read(&sig->count) > count) {

but release_task does

                (this is where atomic_dec(&sig->count) is run)
                takes write lock on tasklist_lock
                remove itself out of PIDTYPE_TGID list

so there's a clear (although small) window between the atomic_dec(&sig->count) and the actual PIDTYPE_TGID unhashing of the thread.

And actually there is no need for all threads to have exited at this point, so we simply kill the BUG_ON.

Big thanks to Marc Lehmann who provided the test-case.

Fixes Bug 5170 (

Signed-off-by: Alexander Nyberg <>
Cc: Roland McGrath <>
Cc: Andrew Morton <>
Cc: Ingo Molnar <>
Acked-by: Andi Kleen <>
Signed-off-by: Linus Torvalds <>

Chris said, yes, he'd add that to the queue for the upcoming release.

6. New CS5535 Audio ALSA Driver

15 Sep 2005 (4 posts) Archive Link: "[RFC 1/1] CS5535 AUDIO ALSA driver"

Topics: MAINTAINERS File, PCI, Sound: ALSA

People: Jaya KumarTakashi IwaiAndrew Morton

Jaya Kumar said, "Appended is my patch adding support for the CS5535 Audio device. I've done this patch against I didn't find the CS5535 pci id in pci_ids so I've added those and the remaining pci functions for the CS5535 device as defines there. I don't have the ability to test the chip's SPDIF capability yet. I'll add support for it next. Please let me know if it looks okay so far and if you have any feedback or suggestions." In addition to the technical stuff, Jaya's patch modified the MAINTAINERS file to list himself as maintainer of the CS5535 audio ALSA driver. Takashi Iwai replied with some small glitches in the patch, and Jaya promised to release a fixed version. Several days later, in a different thread, he did, and Andrew Morton discussed the technical details with him.

7. Russell's Projects

15 Sep 2005 (7 posts) Archive Link: "[PATCH] epca iomem annotations + several missing readw()"

People: Russell KingAlexander Viro

Alexander Viro posted a patch to the EPCA driver, and Cced Russell King in the email. Russell replied, "Thanks for copying me, but I have no interest in any serial driver which doesn't use the serial core interface. I don't want to act as "person to review any change just because the driver says serial" - that's not the role I decided to get involved with." Alexander replied:

Hey, seeing the intensity of your complaints about _not_ being Cc'd... Better safe than serial maintainer ;-)

OK, so what stuff do you want to be Cc'd on? My current approximation would be arch/arm/*, include/asm-arm/*,drivers/serial/*,include/linux/serial*. Well, and any changes of tty interfaces, if I ever get involved in such... Any additions/removals?

Russell replied:

Broadly, it's:

drivers/mfd/* (this fits at the moment, but whether it will in the future depends what else appears there.)
drivers/serial* (though only the drivers in there actually using serial_core - unfortunately some non-serial_core drivers appear to have been placed in there.)

but there are various drivers authored by myself which I'd obviously be interested in CC'ed.

8. Proposed Reorganization For SysFS

15 Sep 2005 - 17 Sep 2005 (27 posts) Archive Link: "[RFC] subclasses in sysfs to solve world peace"

Topics: FS: devfs, FS: sysfs, Hot-Plugging, Ottawa Linux Symposium

People: Greg KHDmitry Torokhov

Greg KH said:

Ok, first off, I hate talking about architecture changes without showing the code for what I am talking about first, but as this is an issue that needs to be agreed upon by a wide range of developers, I'll just write up what I am thinking about doing before actually doing it...

The problem: We need a way to show complex class and class device structures properly in sysfs. Examples of these "complex" views are the input layer's use of different input drivers for devices (usually the same device), the video subsystem view of frame buffer devices and monitors, and even the block layer with it's disks and partitions.

Proposed solutions in the past have been either add the ability to nest classes themselves (as shown in Dmitry's recent proposal for fixing the input layer), or add the ability to nest class_device structures (I think others have tried to do this in the past, sorry for not remembering the specifics.) Both of these proposals don't really solve the real problem, that of the fact that we need to come up with a solution that all of the different subsystems can use properly.

So, here's my take on it. Feel free to tell me what I messed up :)

I would like to add something called "subclasses" for lack of a better term. These subclasses would have both drivers, and devices associated with them. This would show up as the following tree of directories:

        |-- input0
        |   |-- event0
        |   `-- mouse0
        |-- input1
        |   |-- event1
        |   `-- ts0
        |-- mice
        `-- drivers
            |-- event
            |-- mouse
            `-- ts

Here we have 3 struct class_devices like today, input0, input1, and mice. We also have struct subclass_drivers of event, mouse, and ts. These will create the struct subclass_devices event0, mouse0, event1, and ts0. The "dev" node files will show up in the directories mice, event0, mouse0, event1, and ts0, like you would expect them too.

So, this lets us create a solution for the input subsystem, but will it also work for block and video?

For block, yes, I think so. There is no requirement for a subclass_driver to create the subclass devices. Any code can create and register with the class core a subclass device, just set up the parent pointer and away you go. So, in the following instance:

        `-- sda
            |-- sda1
            |-- sda2
            `-- sda3

"block" would represent the struct class. "sda" would represent the struct class_device. "sda1", "sda2", and "sda3" would represent the different subclass devices that are bound to the class device "sda".

And yes, before you all point out the class_interface logic, yes, the subclass_driver stuff looks a lot like this idea. Possibly we could just get rid of the interface stuff and use the subclass_driver logic, but I'd have to look at how people are using the interface logic before I can give a confident answer about that.

Hotplug events would be simple with this scheme, the class stuff would remain the same, and the devpath would just point to the subdir (hotplug events would happen for both the class devices and the subclass devices.) And yes, udev and libsysfs would have to be changed to support this, so we better get this right before pushing it out to the world...

But, what about video devices? David and Pat, we talked about this at OLS, but Pat kept the paper we drew on, and the beer we were drinking at the time has made my memory a bit fuzzy as to all of your requirements for the video subsystem. I remember things about frame buffers and monitors and other things like that, but nothing specific, sorry. Could you outline your needs and I'll see if this proposed structure would solve your issues?

Well, that was a very brief summary, of which I know there are lots of questions for the areas I didn't explain well enough. Comments? Criticisms? Want to see the code before commenting?

There was a little discussion, but nothing that resulted in a modification of Greg's proposal. Dmitry Torokhov was the most critical reviewer, saying that Greg's idea did not make it easy to identify all the input interfaces present on the system. He went so far as to suggest abandoning the whole idea of a 'class', because "This way everything will grow from their respective hardware devices. Class represent a set of objects with similar characteristics. In this regard event0 is no "lesser" than input0. Although they are linked they are objects of the same importance. I do want to see all input interfaces without scanning bunch of directories." But Greg just said, "Not going to happen, sorry :)"

9. Linux 2.6.14-rc1-mm1 Released

16 Sep 2005 - 17 Sep 2005 (26 posts) Archive Link: "2.6.14-rc1-mm1"

Topics: FS: sysfs, Kernel Release Announcement

People: Andrew Morton

Andrew Morton announced Linux 2.6.14-rc1-mm1, saying: (temp copy at

10. Moves To New Home

16 Sep 2005 - 18 Sep 2005 (12 posts) Archive Link: "[KORG] REMINDER: extended downtime"

People: H. Peter AnvinMichael MarineauLinus TorvaldsKees Cook

H. Peter Anvin reported: will be offline starting shortly after 15:00 PDT/22:00 UTC today, September 16, 2005; for a move to the Oregon State University Open Source Lab. This should give much better bandwidth and a more reliable backup solution, in addition to access to a real, staffed NOC.

Special thanks to Javier Henderson for volunteering to fly the machine up there by private airplane, thus minimizing downtime.

It is expected to be back online around 12:00 PDT/19:00 UTC tomorrow, Saturday, September 17. The new IP address of the machine will be

After the move, Michael Marineau replied, "Btw, to any one interested Scott Kveton posted photos of the welcoming party ( here this morning. :-)"

Elsewhere, Linus Torvalds remarked, "Well, it's back up and working, but it looks like mirroring to the public machines may not have been turned on again?" And Kees Cook said, "It was stalled, but I corrected it about an hour ago. It just finished the first update cycle a little while ago, and it is now working on the full daily sync, which will take a while, and then it'll be back to the regular updates cycles again."

11. Linux Released

16 Sep 2005 (2 posts) Archive Link: "Linux"

Topics: Ioctls, Networking, PCI, USB

People: Chris WrightManfred SpraulChris Wright:Linus TorvaldsDave KleikampPatrick McHardyAndi KleenWilly Tarreau

Chris Wright announced Linux, saying:

We (the -stable team) are announcing the release of the kernel.

The diffstat and short summary of the fixes are below.

I'll also be replying to this message with a copy of the patch between and, as it is small enough to do so.

The updated 2.6.13.y git tree can be found at:
and can be browsed at the normal git web browser: (

Note: The above info won't be valid until is back online. In the interim you can find the tarball, patches, changelogs etc. at <>

Summary of changes from v2.6.13.1 to v2.6.13.2

Andi Kleen:

Chris Wright:

Dave Kleikamp:
jfs: jfs_delete_inode must call clear_inode

Ian Abbott:
USB: ftdi_sio: custom baud rate fix

Linus Torvalds:
hpt366: write the full 4 bytes of ROM address, not just low 1 byte
Sun GEM ethernet: enable and map PCI ROM properly
Fix up more strange byte writes to the PCI_ROM_ADDRESS config word

Manfred Spraul:
forcedeth: Initialize link settings in every nv_open()

Maxim Giryaev:
lost fput in 32bit ioctl on x86-64
Lost sockfd_put() in routing_ioctl()

Patrick McHardy:

Willy Tarreau:
Sun HME: enable and map PCI ROM properly

12. git 0.99.7 Released; Cogito 0.15 Released

18 Sep 2005 - 20 Sep 2005 (7 posts) Archive Link: "[ANNOUNCE] GIT 0.99.7"

Topics: Spam

People: Junio C. HamanoPetr BaudisPavel MachekLinus TorvaldsNigel Cunningham

Junio C. Hamano said:

I am hoping that sending this out to the kernel list is not considered too much of useless spamming, but I promise I wouldn't do thit next time for 0.99.8, if I hear from somebody not to.

Here comes GIT 0.99.7

Done in 0.99.7


Some commands and most scripts are renamed for consistency.

For now, we install synonyms as symbolic links so that old names continue to work, but they are planned to be removed in 0.99.8 (or later if there are enough objections on the list -- so far I have heard none).


New Features and Commands

Downloaders that are not fully git aware have been taught about the mechanism to borrow objects from other repositories via objects/info/alternates the server side may be using. 'git fetch' and 'git pull' commands over rsync and http transport should be able to handle such repositories (But not grafts).

People found interesting cases where the 'stupid' three-way merge mechanism does the wrong thing without noticing. We have two new merge algorithms by Daniel and Fredrik that attempt to do better in such cases. A new 'git merge' command has been introduced to make it easier to experiment with and choose among different merge strategies. Note that 'git pull' still uses the traditional three-way merge after downloading, but it is expected to be switched to use 'git merge' sometime in the future.

Importing from tla archives has been improved and documentated.

'git branch' command acquired '-d' flag to delete a branch that has already been merged into the current branch.

'git bisect' command is easier to use by logging the earlier good/bad choices and make it replayable.

'git repack' has -a' flag to pack the whole repository into a single pack.

'git grep' is a new command to run grep on files '/git/index.html' knows about.


Nigel Cunningham asked for a URL, and Chris White pointed to the page ( . Elsewhere, Petr Baudis took the opportunity to announce:

this is the release of Cogito-0.15. It fixes several minor bugs, and adds a feature or two. The most important thing though is that this depends on Git-core-0.99.7 and uses the new command names. Everyone is encouraged to upgrade at least to this Cogito version in the next few days, since the older Cogito versions likely won't work with the future Git-core releases.

To stay in sync with the Git terminology, Cogito also renames its cg-pull to cg-fetch. Since this is a major naming change (I'm not too happy about it, personally), cg-pull will stay aliased to cg-fetch for at least one (likely two) next major Cogito releases (it also produces a warning when invoked as cg-pull). In the more distant future, cg-pull will slowly become the new name of cg-update, to make it confusing.

While at it, we also renamed the *-id scriptlets to cg-*-id. Other notable stuff is cg-init respecting the ignore rules, and better UI for cg-add wrt. directories (including cg-add -r support).

Now let's see what the usual bug-right-after-release (major release, so a major bug?) will be this time.

Pavel Machek asked, "Could we keep at least the cg-update name? It is certainly not a *pull* because it does update local repository (and tree, too)." Petr replied, "AIUI, that's what makes it a pull for *cough* some people. ;-)" He added, "I want to retain it. I'm not 100% decided yet whether to actually use the pull term for anything in Cogito. Previous usage reportedly confused some, the new usage actually confuses me and apparently some other people. So I might just avoid the 'pull' term in the future altogether. Not decided yet, though, and opinions obviously welcomed." Linus Torvalds also replied to Pavel, saying that he was the "some people" Petr referred to. He said updating a local repository from a remote was exactly what "pull" meant. He added, ""fetch" is the one that only updates the history. A "pull" also does a merge and updates the current branch _and_ the currently checked out tree."

13. Status Of PWC Driver

19 Sep 2005 (3 posts) Archive Link: "PWC 10.x driver in the kernel?"

Topics: Philips Webcam Driver, Spam

People: Joshua KwanAlistair John Strachan

Joshua Kwan asked, "I've just acquired a Logitech webcam and I couldn't get it to work with the version of the PWC driver currently in the kernel. Given all the contention about PWCX etc., are there plans to merge in the new 10.x version of the driver available at (This version does work with my webcam.) Just like the one in the kernel tree right now, this version does not require pwcx at all (the binary blob was reverse-engineered), so I think it's a big improvement," Alistair John Strachan replied, "Even if the reverse engineered component was deemed unacceptable, I'd like to see the (other) differences between the two drivers merged ASAP. AFAIK, the 10.x pwc driver supports the v4l2 API which is useful, and as you mentioned actually works on more camera (the 9.x versions just spam errors to dmesg on my PWC740K)." But there was no further discussion.

14. Linux 2.6.14-rc2 Released

19 Sep 2005 - 21 Sep 2005 (38 posts) Archive Link: "Arrr! Linux v2.6.14-rc2"

Topics: Disks: SCSI, Kernel Release Announcement, Sound: ALSA

People: Linus TorvaldsMartin J. BlighJames Bottomley

On International Talk-like-a-pirate Day ( , Linus Torvalds announced Linux 2.6.14-rc2, saying:

Ahoy landlubbers!

Here be t' Linux-2.6.14-rc2 release.

Not a whole lot o' excitement, ye scurvy dogs, but it has t' ALSA, LSM, audit and watchdog merges that be missed from -rc1, and a merge series with Andrew. But on t' whole pretty reasonable - you can see t' details in the shortlog (appended).


Martin J. Bligh, with absolutely no smile, reported, "SCSI is broken in several cases by a lack of the patch below, which means some of the regular test boxes can't - James, any chance of getting that one upstream?" James Bottomley replied, "It already is ... unfortunately just after 2.6.14-rc2, but if you use the latest git head you should get it." And Martin was pleased.

15. kprobes Maintainership

21 Sep 2005 (1 post) Archive Link: "Updating maintainers list with the kprobes maintainers"

People: Prasanna S. PanchamukhiDavid S. MillerAnanth N. Mavinakayanahalli

Prasanna S. Panchamukhi posted a patch to list himself, Ananth N. Mavinakayanahalli, Anil S. Keshavamurthy, and David S. Miller as official maintainers of kprobes. There was no discussion.







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.