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 #88 For 9 Oct 2000

By Zack Brown

Table Of Contents


Frederic Stark once again noticed the archive links were missing last issue. Thanks again, Frederic (and again, and again... ;-)

Thanks also go to Andy Ward for catching a typo in one of the titles to last week's issue, specifically in Issue #87, Section #12  (22 Sep 2000: es1371 Sound Card Catches Bad Fixes) I had originally called the card "es371". Thanks lot, Andy!

Lars Ehrhardt also pointed out several spelling mistakes in last week's issue, although most of them were misspellings in quoted text. I fixed the rest. Thanks, Lars!

Just a quick comment on spelling errors in quoted text. It's not a bug, it's a feature ;-)! If you cut-and-paste some quoted text into a list-archive search engine, a spelling error will give you a dead-on match every time. Whereas if the text you're cutting-and-pasting contains a spelling correction, you may match several places in the archive, but none of them will be the one you want.

That said, I have to admit I do occassionally make corrections to the quoted texts, to clear up ambiguities.

Just a little balancing act, this thread summary stuff...

Mailing List Stats For This Week

We looked at 1192 posts in 4673K.

There were 360 different contributors. 157 posted more than once. 141 posted last week too.

The top posters of the week were:

1. Driver Directory-Structure Tweaks

20 Sep 2000 - 26 Sep 2000 (21 posts) Archive Link: "lvm in 2.4.0-test9pre5"

Topics: Device Mapper, Disk Arrays: LVM, Disk Arrays: RAID, FS: ext2, Source Tree, Virtual Memory

People: Andrea ArcangeliLinus TorvaldsJeff GarzikPeter SamuelsonMohammad A. HaqueJan Niehusmann

In the course of discussion, it came up that 'lvm' hadn't been moved into the 'drivers/md' directory as it should have been, which broke 'lvm'. At one point, Andrea Arcangeli said, "LVM and MD have nothing common. They're two completly orthogonal piece of code (you can put LVM on top of MD but that's just because of the nice reentrance of the blkdev API as you can run loop on top of ext2 on top of ramdisk). I don't think it's good idea to mix LVM and MD in the same directory. LVM should live in drivers/lvm not drivers/md." Jan Niehusmann, Mohammad A. Haque and Peter Samuelson agreed, but Linus Torvalds replied:

I disagree.

Yes, they have no _code_ in common. They have a completely distinct history, and they have distinct users.

But they are, in the end, the same thing. They are higher-level drivers that do conceptually the same thing, namely manage the low-level drivers as a potentially common resource.

In fact, some of the MD and LVM code do the same things. CONFIG_MD_LINEAR and CONFIG_BLK_DEV_LVM can be used to do the same thing (and I think LVM can do striping too). Yes, they have different interfaces, but they have the same issues.

It makes sense to group them together. Neither is a true hardware driver, and they have many common goals.

This made sense to Andrea, but he recommended 'drivers/sm' (Storage Management), with 'drivers/sm/lvm' and 'drivers/sm/md'. Peter pointed out that there was overhead for splitting driver directories, and that it shouldn't be done on a whim. He also felt that 'sm' was too broad, since other drivers could also fit into the "storage management" category; and that 'lvm' was too narrow, referring to a specific implementation; and that 'md' was also specific only to RAID devices. He suggested 'drivers/block/pseudo' or 'drivers/block/meta'. Jeff Garzik replied, "md = metadisk or multiple disks. Either, lvm applies :)" And Linus went on:

Yes, we have all thes _historical_ reasons why people think "md" refers to the particular RAID code in question. But so what? LVM is also very much an issue of handling multiple disks, and organizing them. "md" as shorthand for "multiple disks" works fine for LVM too.

I think most people who complain about the "md" directory naming do so just because they have this emotional attachement to "md" as the particular implementation that it implied a year ago, and they've gotten used to that association.

But I don't think there is anything wrong with grouping RAID and LVM under the title "md", and just leaving it as such.

If you look at pre6, the comments changed a bit to make it clearer that MD now includes both LVM and RAID as equal partners, and I don't see any problem with that setup. Does anybody have any real technical arguments against it, or are all arguments of the type "I'm used to 'md' meaning RAID, and I am not willing to reconsider"?

Sure, it could be called "sm" for "storage management" too. Or "dm" for "disk management". Or it could be under drivers/block/multi. Or it could validly be called any number of things. I just think that "md" was a valid name too, and I got the patch with that name, so..

Peter replied, "It's a documentation issue as much as anything, and you've basically taken care of that in -pre6." And Andrea agreed.

2. The Return Of 'classzone': The VM Saga Continues

24 Sep 2000 - 29 Sep 2000 (262 posts) Archive Link: "GFP_IO && shrink_[d|i]cache_memory()?"

Topics: Virtual Memory

People: Andrea ArcangeliRik van Riel

In the course of discussion, Andrea Arcangeli indicated that his 'classzone' approach to the virtual memory subsystem was far from dead. He said:

I'll soon (as soon as I'll finish some other thing that is just work in progress) release a classzone against latest's 2.4.x. My approch is _quite_ different from the curren VM. Current approch is very imperfect and it's based solely on aging whereas classzone had hooks into pagefaults paths and all other map/unmap points to have perfect accounting of the amount of active/inactive stuff. The mapped pages was never seen by anything except swap_out, if they was mapped (it's not a if page->age then move into the active list, with classzone the page was _just_ in the active list in first place since it was mapped).

I consider the current approch the wrong way to go and for this reason I prefer to spend time porting/improving classzone.

In classzone the aging exists too but it's _completly_ orthogonal to how rest of the VM works. classzone had only 1 bit of aging per page to save mem_map_t array so I'll extend the aging info from 1 bit to 32bit to make it more biased.

This is my humble opinion at least. I may be wrong. I'll let you know once I'll have a patch I'll happy with and some real life number to proof my theory.

In the meantime if you want to go back to 2.4.0-test1-ac22-class++ to give it a try under swap to see the difference in the behaviour and compare (Mike said it's still an order of magnitude faster with his "make -j30 bzImage" testcase and he's always very reliable in his reports).

There followed a long (and peaceful) debate over the relative technical merits of Rik van Riel and Andrea's respective implementations. It seems that the ultimate decision will have to be made by experience of which implementation actually works better. This will also be very difficult to gauge, since no universal benchmarks have been found (or perhaps can be found) for virtual memory, and any implementation is likely to do well under certain loads and poorly under others. It may be that in the absense of demonstrable superiority of one implementation over the other, the final decision might have to be made based on the simplicity and elegance of the code. In that case, I believe everyone (even Andrea) agrees that Rik's code is simpler than Andrea's. On the other hand, Andrea claims his implementation is a tremendous speed improvement over Rik's, which if true, may be enough to push it over the edge into acceptance. Two other points add to the complexity of the situation: first, Rik is the official maintainer of the VM subsystem, and may have a slight bias toward his own implementation. Also, Rik's code is currently in the official sources, giving it the benefit of more eyes and coders than Andrea's 'classzone' patch. What all this will mean for the final outcome is anybody's guess. Time will tell.

3. Calling User Apps From The Kernel

2 Sep 2000 (2 posts) Archive Link: "Calling userspace apps from within kernel"

Topics: Kernel-Space Versus User-Space

People: Daniel WallsErik Andersen

Daniel Walls asked "if it is possible to execute a userspace application from within the kernel," and Erik Andersen replied:

static char * envp[MAX_INIT_ENVS+2] = { "/kernel-traffic/HOME=/index.html", "TERM=linux", NULL, };

Just because you can do something does not, however, make it a good idea...

4. 'gcc' 2.96 And The Kernel

26 Sep 2000 (8 posts) Archive Link: "["Michael N. Lipp" <>] Can't compile linus 2.2.17 with latest gcc due to checksum.S"

Topics: Compiler

People: Horst von BrandErik MouwTimur TabiJakub Jelinek

Version Control

Michael N. Lipp was unable to compile the latest kernel with the latest compiler; and Jakub Jelinek and Horst von Brand stopped him right there. Horst said, "linux-2.2.x are strictly egcs-1.1.x or gcc-2.95.x at the latest. 2.96 won't work, and it won't be fixed." Timur Tabi asked why 2.96 was so screwed up, and several folks replied to this.

Horst said, "It's the kernel which is screwed up, not the compiler. The kernel uses gcc-specific (even version-specific) hacks all over the place. gcc-2.96 isn't yet (and perhaps won't ever be), and it is just a step towards gcc-3.0, which _is_ a large change."

Erik Mouw put it, "There is no such thing as gcc-2.96. The official GCC release is still gcc-2.95.2. A couple of vendors (RedHat, for example) took a snapshot from the CVS sources and branded it as gcc-2.96, but that's a known unstable development snapshot."

5. SparcLinux On Sun E10000

27 Sep 2000 (5 posts) Archive Link: "SparcLinux on Sun E10000"

Topics: Big Memory Support, Porting Linux, Samba

People: Anton BlanchardBert HubertPeter RivalPete ZaitcevIgmar Palsenberg

Anton Blanchard announced:

Patches for Sun E10000 are in the current vger cvs, details for accessing this can be found at <>. You too can have a linux box that compiles kernels in 20 seconds.

I have set up some information at:


Thanks to Craig Armour <>, Tony Jago <> and Mark Suter <> from the University of Queensland for arranging access to such a machine.

Igmar Palsenberg glowed with joy, and Bert Hubert said of the 23824288k of RAM, "This must be some kind of record." But Peter Rival corrected, "Sorry...check the post I made a few hours ago. Unless I count my digits wrong, that's ~24GB of memory. The GS320 we booted here a while ago has 256GB. Either way, tho', that's a _lot_ of memory!"

Elsewhere, Pete Zaitcev remarked, "Is it a coincidence that E10000 is officially declared obsolete today? Sun never allows us to use the latest and greatest hardware."

6. Linux On AlphaServer GS320

27 Sep 2000 - 30 Sep 2000 (7 posts) Archive Link: "Linux boots on Wildfire^WGS320!"

Topics: Big Memory Support, Porting Linux, Scheduler, Virtual Memory

People: Peter RivalPavel MachekAndrea ArcangeliRik van Riel


Peter Rival announced, "Well, I'm finally getting around to sending out this announcement. As can be seen on, we've managed to boot Linux on an AlphaServer GS320. The only caveats are that one of the CPUs was out of the system at the time (hence 31 CPUs, not 32), and that we haven't yet finished the DISCONTIGMEM support for Alpha (hence the 480GB of memory, instead of the real 256GB). Needless to say, things like kernel builds run _really_ fast. Heck, I could put all of my workstation (several times over, in fact) into RAM on this thing! I'm gonna have to put a graphics head on this and see how Quake runs... ;)"

Pavel Machek replied hungrily, "I want that machine! Hmm, would it fit in my room?" And Andrea Arcangeli said:

It depends on the size of the room of course, but it wouldn't fit in mine and you also need 3phase electricity connection to have a chance to power it up :). Pretty amazing. I ported linux to it and booted the linux kernel the first time into it in April this year with the kind help of Jay Estabrook (the machine I was using for doing the port had ""only"" 11 CPUs and 8G of ram :).

To make it to work faster when the memory and CPUs of more of one node are used by linux (btw currently we can't run more than one linux kernel at once) we need to do real NUMA (not only DISCONTIGMEM). That means at least duplicating the kernel on each node, and adding NUMA heuristics into scheduler and allocator along the lines of what SGI folks are doing for Origin 2K.

The allocator also mandatory needs part of classzone to be able to make decent decisions. (putting the memory of different NUMA nodes internally to a pgdat_t as different zones as it's been proposed in linux-mm is a broken hack that can't work right) Infact saying that classzone have problems with NUMA looks silly to me as it's the other way around as far I can see.

To this last VM comment, Rik van Riel replied:

Both the current code and classzone will need some adjustments to work fine (as in: reasonably efficient) with NUMA.

If the classzone idea can be extended to NUMA with more readable (== maintainable) code than the standard zoned allocator, I'm all for having it integrated...

(I'm not sure if classzone will have many benefits in "normal" setups, but with NUMA I can see the idea giving a lot more performance benefits)

7. Angry Fighting In The ARM Tree

27 Sep 2000 - 29 Sep 2000 (43 posts) Archive Link: "Russell King forks ARM Linux."

Topics: Development Philosophy, Porting Linux, USB

People: George FranceMark HahnAlexander ViroRussell KingErik MouwAlan CoxMiles Lane

George France from Compaq, said, "As you probably know Russell King is the maintainer of ARM Linux. Him and I have been debating how serial ports should be handled on an off for months now. IMHO, today he lost it, declaring that he was going to block all e-mails from Compaq, which means he can not recieve any more ARM Linux patches from us. I have tried every method that I know of, to work with him, but he has cut off all commutations. So starting tomorrow, we will be submitting patches directly to the kernel mailing list, since Russell will not even receive our e-mails. I will also be setting up an ARM mailing list and web pages, for those that wish to participate. It is too bad that Russell has decided to create a fork in the ARM Linux tree. It is his choice." Mark Hahn replied:

uh, this will be unpleasantly familiar to anyone who was reading the linux-usb mailing list in Dec 99, when George said, roughly "you are all so full of shit that you're not worth working with, so on Monday we will begin designing our own USB for Linux".

Linux USB has survived quite nicely in spite of this, which bodes quite well for ARM-linux ;)


Mark has since issued a retraction of the above statement. Quoting his own post, he said:

"I posted the following message here some weeks ago. I formally apologize to George France, and to the list for my message, and formally retract it.

The quotation in my message was my own, personal interpretation; George France did not say those words.

I certainly never intended to misrepresent George France, and I sincerely apologize to George France for any misunderstandings I may have caused."

-- Ed: [14 Nov 2000 00:00:00 -0800]

Miles Lane felt that no maintainer should refuse patches from an entire company; and that Compaq and Russell should continue to try to work out their differences. He also suggested that the Linux community should draft a proposal for how to pick a maintainer. Alexander Viro replied:

Since when it is decided by community? It's not a democracy. You don't like it - maintain your tree and accept/reject whatever you want.

I find plonk-by-domain silly, but the contents of filters is the private business of person using them. Period. We've been through that quite a few times when Alan-uses-*R*S threads appeared on the list. Enough, already.

David Howell agreed with Miles, and added that only the technical aspects of the discussion had any place on linux-kernel.

Elsewhere, Russell spoke on his own behalf:

Please note that at every instance, George has totally ignored my suggestions and advice. I have ended up taking this last straw to prevent any further flame wars or other nastyness between us.

I therefore believe that it is in the greater good for the ARM Linux community that discussions between George France and myself cease.

George replied:

Every instance??? I think this is an exaggeration, don't you? If you really want to prevent a flame war stop poking at me.

As I said in my last message to you, I am tired of arguing with you.

Erik Mouw posted a summary of the argument, and added, "We are currently trying to solve this issue privately, so the last thing we can use is another flamewar on this list. Please help me to solve this issue by not putting more fuel on this fire." Elsewhere, Alan Cox also asked for a URL to the discussion, commenting, "It looks like a fun read." Russell gave a link into the archives and said to search for a thread with "Subject: Re: information request about serial driver". After reading it over a lot of people (including Alan) agreed with Russell's side of the technical issue; at one point George remarked in regards to Russell's refusal to accept patches from them, "now we will have to send our patches to the kernel mailing list, setup out own mailing list and web pages. It is not a problem since we already have a web site setup." Alan replied, "Personally I'd rather you accepted that everyone else agrees with Russell about the major/minor issue and that -both- of you then stopped behaving like five year olds. Everyone does stupid things now and again and if you could both go back to being sane life would be far simpler."

8. More VM Fixes

27 Sep 2000 - 29 Sep 2000 (5 posts) Archive Link: "2.4.0-t9p7 and mmap002 - freeze"

Topics: Virtual Memory

People: Rik van RielRoger Larsson

Roger Larsson reported a VM lock-up, and in the course of discussion Rik van Riel said:

I'm finally back from Linux Kongress and Linux Expo and will look at the latest tree and integrate the fixes I made while on the road later today (after I get some sleep).

I have fixed this particular bug, which was caused by us moving unfreeable pages to the inactive_dirty list and back again, while not accomplishing anything useful.

The fix for this is trivial and I'll post it later today (cleaned up and working in the current source tree).

9. Multi-Threaded Core Dumps

29 Sep 2000 - 3 Oct 2000 (21 posts) Archive Link: "Anyone working on multi-threaded core files for 2.4 ?"

Topics: Debugging, Executable File Format

People: Richard MooreJames CownieIgmar PalsenbergMarty Fouts

James Cownie asked if anyone were working on enabling multi-threaded core files. Richard Moore from IBM replied:

Yes we (IBM Linux Technology Center RAS Team) are. If you have ideas/concerns/requirements please make them known. We are at the point of deciding what to attack. We have other dumping technologies on other OSs we could model a Linux enhancement on. There are many things we'd like to see incorporated, the question is how not to boil the ocean. Here are some of the ideas we are thinking about:

James continued:

I was aiming at the simplest and in my mind most obvious thing, which is to have the standard ELF coreer dump handle multiple threads in the same way as it does on many other systems. The lack of these causes shrieks of amazement from many of our customers :-(

This is not rocket science, and there are already debuggers (gdb, our product TotalView, ...) which know how to understand such core dumps if only the kernel produced them.

Now that the kernel has mechanisms for finding all the threads in a process, the actual dump writing should be relatively simple. (You need to write the appropriate register notes for every thread, rather than just one).

You seem to be aiming for a much more featureful solution (also applicable to checkpointing ?), I'm simply aiming to catch up with existing practice on many other operating systems.

There followed an interesting discussion of the technical details, in which at one point Igmar Palsenberg remarked, "I think you need to sync the threads so that the're in the same state. And I don't think it's that simple." To which Marty Fouts replied:

I think one needs to be careful of not letting a desire for the perfect solution prevent deploying a useful solution while working out the best one, in this case.

When a multithreaded application "dies" due to one of the threads failing in an unexpected and unrecoverable way, there probably isn't, at that point, a "same state" for the threads to be in, and an non-coherent dump, while still difficult to use, is more useful than not dumping any state at all, and often is coherent enough to use anyway.

10. Redesigning Or Getting Rid Of '/proc/locks/index.html'

1 Oct 2000 (9 posts) Archive Link: "[RFC] Imminent death of /proc/locks predicted; film at 11"

Topics: FS

People: Matthew WilcoxAlan CoxPeter SamuelsonAlexander Viro

Matthew Wilcox said:

Does anyone actually want /proc/locks to stay? The data structure which allows it to be generated is now only used by the code to print out /proc/locks. If it could be deleted, a lot of code and data pointers could go away. I don't think any program depends on its existance and it's a pretty ugly file anyway (exposing kernel pointers to userspace? looks like pure debug code).

Speak now, or it shall be gone.

Alan Cox preferred to keep some mechanism around for viewing locks, for debugging purposes, though regarding getting rid of '/proc/locks/index.html' he added, "If it makes the code far cleaner then I have no objection. If we can do a simple (different format even) /proc/locks to replace it that scores double points ;)" Alexander Viro also suggested changing the name to something like '/proc/fs/locks/index.html'. In a later post, Alan also remarked, "All I care about is what locks are currently in force in the system. So for example I can do something like 'showlocks /var/spool/mail/alan'." Matthew replied that there was already a 'fcntl' that could do that, although it would be slow and imperfect. Peter Samuelson posted some code that tried to solve the problem in user space, but Matthew had technical objections, and the thread ended.

11. Microsoft Withdraws Linux NTFS Threats

1 Oct 2000 (10 posts) Archive Link: "Microsoft Withdraws Linux NTFS Threats"

Topics: FS: NTFS, Legal Issues, Microsoft

People: Pat ChristianRik van RielJeff V. MerkeyAndre Hedrick


Continuing from Issue #86, Section #13  (14 Sep 2000: Possible Microsoft Litigation Over NTFS Support In Linux) , Jeff V. Merkey announced that Microsoft had apologized and withdrawn the threat of legal action. He quoted an article by Pat Christian from the Daily Herald:

OREM -- The CEO of a local computer company says Microsoft has backed off on a threat to sue his Orem company over alleged violations of intellectual property rights.

"Their attorney, Linda Norman, called us Thursday night and issued an apology," Jeff Merkey, CEO of Timpanogas Research Group in Orem, said in a phone interview from the Networld Interop trade show in Atlanta on Friday. "She assured our attorney, Andrew McCullough, that there will be no lawsuit."

Microsoft spokesman Jim Cullinan said he couldn't immediately speak of the agreement between Bill Gate's company and Timpanogas.

However, he did say, "There is no truth there is a lawsuit, but Microsoft does take its (intellectual property) rights very seriously."

"It all kind of got out of proportion," Merkey said of the threats. He spoke about them only after some of his private e-mail was intercepted and posted on the Internet.

Timpanogas is a corporation formed by Merkey and other former Novell employees to develop networking, clustering and storage software solutions. The company had been working with Microsoft engineers on Timpanogas network file system products for Microsoft's Windows NT 2000.

Development involved Microsoft intellectual property. Like a lot of software companies, Timpanogas was also working with other operating-system developers that Microsoft considers competitors, such as Linux, developing Timpanogas network products that would run with Linux.

"They (Microsoft) basically gave us a license to build some tools to run on Windows NT 2000," Merkey said.

At one point, Timpanogas wrote some conversion tools to convert NetWare and Linux file management systems and were giving them to Microsoft.

But he said they also gave them to some Microsoft customers who were using the Microsoft network file systems on Linux.

But Merkey said this and his e-mail communications with Andre Hedrick, a Linux disk engineer, ruffled Microsoft's feathers.

"Microsoft has threatened us with litigation due to our support of Linux NTFS development, and we have dissolved our NTFS licensing agreements with Microsoft...," Merkley wrote in one of his e-mails.

Merkey said he has no idea how it happened, but their e-mails first were posted on an Internet weekly Linux newsletter and reposted Tuesday on

Merkey said Norman described the fracas as "an apparent miscommunication. And she also said 'please don't post those e-mails.' "

Pat Christian can be reached at 344-2556 or at

Rik van Riel remarked:

Maybe MS made this decision because they weren't willing to force users into making the choice of either continuing to use NT or permanently ditching it without the chance of going back ;)

(and when somebody has an NTFS volume and wants to use Linux with it, it's not that hard to guess which way they're migrating their system)

Jeff gave some details:

They semed very sad that they had damaged their relationship with me, and Linda was more concerned as to whether I was still angry at them more so than any issues with their IP. I really like a lot of the folks who work up there, particularly Jim Allchin and David Geobel (and Dan Neault -- he's really a great guy) and I think they did not like the idea that one of their golden geese might fly away forever. I am happy to work with them moving forward. I just don't respond well to threats, and never have -- but who does.

They are really stressed up there right now with the DOJ stuff and everything that's happenned, and I think the whole Linux thing is also getting them down. We'll see where it goes, but I am gad they are doing what's right here and putting their customers first. If an MS customer wnats to use Linux and W2K, they should be helping them, and I think perhaps they have come to realize this now.

Rik replied:

People are starting to realise they have a choice, so MS will have to become more customer friendly.

Even if Linux doesn't "win the game", knowing that we did something to make computing bearable again for the system administrator is a good thing ;)

Elsewhere, Andre Hedrick replied to Jeff's initial post:

It is fun, but I was not ware that scale of this mess was so great. All I did was to make the request for Microsoft not to blow things out of proportion. Sheesh, by letting us, without noise or action, create R/W support of NTFS for Linux they would have been able to give the appearence that they were behaving.

Regardless, congrates on using the entry point. I just hope everyone at Mircosoft is still there. I would feel really bad if an aquiantence of my there had reprocussions. We would need to find a way to help them out, if they took it on the chin for us.

12. Status Of Kernel Debugger

1 Oct 2000 - 2 Oct 2000 (7 posts) Archive Link: "where is the kernel debugger?"

Topics: Debugging, FS: sysfs

People: Keith OwensKeir FraserIngo MolnarDavid Ford

David Ford asked where to find the current release of the kernel debugger, and Keith Owens gave a link to the KDB download directory and replied, "Stay away from 1.5-beta for the moment unless you like debugging the debugger. No patch against 2.4.0-test9-pre7 yet, hopefully later today." Elsewhere, under the Subject: [Announce] kdb v1.5 is available, Keith announced: contains a patch for kdb v1.5 against 2.4.0-test9-pre8.

Changes from kdb v1.5-beta2.

This version of kdb also includes :-

Expect the configuration method and the use of /proc/sys/kernel/nmi_watchdog to change in future. Ingo Molnar and I are discussing how much of the NMI oopser for uniprocessors should go into the standard kernel.

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.