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 #247 For 31 Dec 2003

By Zack Brown

Table Of Contents

1. Status Of "Linux Device Drivers"

18 Dec 2003 - 21 Dec 2003 (15 posts) Archive Link: "Linux Device Drivers 3rd Edition"

People: Jonathan CorbetXavier BestelJose Luis Domingo Lopez

Kendrick Hamilton wanted to write a character device driver, and wondered if there would be a 3rd edition of Linux Device Drivers that would cover the 2.6 kernel. Alternatively, he wondered if the 2nd edition would be good enough to rely on for a character device driver. Jose Luis Domingo Lopez and Xavier Bestel recommended some Articles at LWN; Jonathan Corbet, coauthor of Linux Device Drivers, also recommended those articles. Of a potential 3rd edition, he added, "There will, but don't hold your breath - it's proceeding more slowly than we would like."

2. Patent-Encumbered Code Explicitly Rejected From Linux

18 Dec 2003 - 22 Dec 2003 (27 posts) Archive Link: "[OT] use of patented algorithms in the kernel ok or not?"

Topics: Networking, Patents

People: Lennert BuytenhekLinus TorvaldsAdrian Cox

Lennert Buytenhek said, "There's a fast algorithm for longest-prefix match (as used in IPv4 routing table lookups) which I have implemented, and would like to submit for inclusion into the kernel (when 2.7 opens.). However, I am aware that there is a patent on this algorithm, exclusively licensed to a major manufacturer of networking equipment." He wanted to know if it was OK to send in the patch, or if he should look for an unencumbered algorithm. Linus Torvalds replied, "Don't submit, and find an unencumbered algorithm. Unless you can get the patent holder to grant a license (it does happen)."

Elsewhere in the thread, Adrian Cox remarked:

For examples of source code distribution in a patented area, look at MPEG4 projects, particularly MPEG4IP. has source code under a variety of licenses including GPL, and the front page has the following disclaimer: "This code is not intended for end users, and does not contain executables. Please read all the legal information to determine if it is suitable for you."

The project was started by Cisco, who likely did some legal research first. Cisco, however, have the resources to see off frivolous lawsuits, while individual developers do not.

3. Real-Time Maintainership; Nanokernel Maintainership; Patent Policy

18 Dec 2003 - 21 Dec 2003 (13 posts) Archive Link: "[PATCH] Updating real-time and nanokernel maintainers"

Topics: MAINTAINERS File, Microkernels: Adeos, Patents, Real-Time: RTAI, Real-Time: RTLinux

People: Zwane MwaikamboKarim YaghmourNick PigginLinus TorvaldsLarry McVoyPhilippe GerumJoern EngelVictor Yodaiken

Karim Yaghmour posted a patch to add Philippe Gerum as the Adeos maintainer, removed Victor Yodaiken as RTLinux maintainer, and added Paolo Mantegazza as the RTAI (Real-Time Application Interface) maintainer. Zwane Mwaikambo suggested leaving Paolo out of the maintainer list along with Victor, because "neither have code in the kernel." Karim replied, "RTLinux has never had code in the kernel, but it still had a mention in the maintainers file for quite a number of years. I think that these entries are really pointers for those who are interested in this area of Linux's use. As such, RTAI is the only real free software real-time Linux extension and I think it deserves mention. Nowadays, is only an alias for, which I think pretty much sums up the situation." Zwane replied, "But you're forgetting what the MAINTAINERS file is for. I can't but help thinking that this is linked with the email you sent earlier, but that's just me. Frankly i reckon this particular case could be settled by removing both from MAINTAINERS as neither has code in the 2.6 linux kernel. Anybody looking for realtime Linux kernel capabilities can just do a Google." Karim replied that it would be best to let the decision-makers decide on the merits of the patch; but Nick Piggin said he also agreed with Zwane. He said, "People have enough trouble using MAINTAINERS as it is. Using it to pat each others backs makes it less useful. As Zwane said, neither have code in the kernel, so I don't see how you think it is justified...?" Karim replied, "It is justified in the same way that the RTLinux entry was justified for those many years. But the bottom line is as I said it before, I personally have no stake in this, and I certainly don't want to start a debate on the use of the MAINTAINERS file, others are much more apt than myself to make the proper judgement call on the proper use of that file." Joern Engel also said RTLinux wasn't justified in having a MAINTAINERS entry, and so RTAI should be taken out as well. At this point Victor said he actually did have code in the kernel at one point; and Karim said:

Are you saying that there's code in the kernel that is subject to your patent?

If there is, then it should definitely be taken out. First, as Linus has stated recently (and as has been the policy for a while), the kernel should avoid having any patented code ( Second, "RTLinux Free" is being ported over to Adeos (

Linus Torvalds replied:

That's not true.

The kernel should have no patented code THAT DOESN'T HAVE A LICENSE.

There are several cases where this came up: RCU is one obvious one, but there were also issues with Intel's initial submissions of some of the networking drivers where they didn't want to originally release under the GPL because of worrying about patents they owned.

The email you quote expressly says "unless you can get the patent holder to grant a license". And the RTLinux patents were licensed to GPL'd projects. See the RTLinux "open patent license".

I don't understand why people continually complain about the RTLinux patents. I bet it's because Victor has all the easy charm of Larry McVoy, but I don't see why people still continue to spread obvious mis-information about the situation.

It's doubly discgusting with some of the people who were trying to spread all the FUD and mis-information were doing so because they were themselves doing a non-GPL microkernel, and they complained about how the patents were somehow against the GPL and wanted to get community support by trying to make out the situation to be somehow different from what it was.

I'm not a supporter of software patents, but while I dislike them, I don't dislike them _nearly_ as much as I dislike dishonest people.

4. Using Distcc With 2.6

19 Dec 2003 - 20 Dec 2003 (2 posts) Archive Link: "Distcc & 2.6.0"

People: Dan BrowTomas Szepe

Dan Brow asked, "is any one using distcc with 2.6.0, the kernel will not compile with distcc, it goes through the compile process and then I have to recompile with just make." Tomas Szepe said he himself had no problem using distcc version 2.9.

5. Status Of Large Filesystem Support

20 Dec 2003 - 22 Dec 2003 (5 posts) Archive Link: "Is there still at 2TB limit?"

People: Dale AmonJose Luis Domingo LopezPeter Chubb

Dale Amon "ran across old discussions on a patch for the 2TB file system size problem. Is this standard in 2.6.0 kernels? What filesystem size and file size limits are there currently?" Jose Luis Domingo Lopez replied:

In 2.6.x kernels you are also limited by the 2 TiB limit on block device sizes, limit which you can extend compiling a 2.6.x kernel with "Large Block Device" support (menu "Device Drivers" -> "Block devices", at the end).

You will also need filesystems that support that big sizes and can hold big files on them, have a look at the following URL for more information:

Dale took a look at that site, and noticed it was a little old; he asked if there were current libraries that would work with LFS; but later replied to himself, "I've got the answer. glibc 2.1.3 has full api; glibc 2.2 has full support; I'm currently using glibc 2.3.2ds1 so if I toggle on that LFS option, it should all just work merrily with many terries of bytes." Peter Chubb also said:

Yes. Most glibc are distributed compiled with _LARGEFILE64 support.

See also I haven't got around to updating for 2.6.0, but the 2.5 notes still apply.

6. perfctr-2.6.3 Released

21 Dec 2003 (1 post) Archive Link: "perfctr-2.6.3 released"

Topics: Profiling

People: Mikael PetterssonPavel Machek

Mikael Pettersson announced:

Version 2.6.3 of perfctr, the Linux/x86 performance monitoring counters driver, is now available at the usual place:

Version 2.6.3, 2003-12-21

7. Larry Unsubscribes From linux-kernel Mailing List

23 Dec 2003 (1 post) Archive Link: "Re: RFC - tarball/patch server in BitKeeper"

Topics: Version Control

People: Larry McVoyZack Brown

Continuing from Issue #246, Section #6  (14 Dec 2003: Larry Pulls Another Larry) , Larry McVoy of BitMover said, "I've unsubscribed from the Linux kernel list, this is a good example of why. No sense of humor on your part, and you are whining about a license on a 200 line chunk of code. Any decent programmer could have reimplemented it in less time than it took you to complain."

(ed. [Zack Brown] If this impacts BitMover's responsiveness to BitKeeper bug reports and feature requests from kernel developers, it might inspire more kernel folks to check out arch and other alternatives. But a big push for arch or any other revision control system should probably not be expected in the short term.)

8. Linux 2.4.24-pre2 Released

22 Dec 2003 - 23 Dec 2003 (7 posts) Archive Link: "Linux 2.4.24-pre2"

Topics: Big Memory Support, FS: XFS, Power Management: ACPI, USB, Virtual Memory

People: Marcelo TosattiMike FedykXose Vazquez Perez

Marcelo Tosatti announced Linus 2.4.24-pre2, saying, "It contains MIPS/PPC64/SPARC updates, ACPI bugfixes, USB update, XFS fixes, amongst others." Mike Fedyk asked, "Do you plan on merging any more of the VM from Andrea in this release (or future releases)?" Marcelo said, "Yes, I believe I will merge inode-highmem and a few others probably." But Xose Vazquez Perez said, "Andrea said that there are two patches missing: inode-highmem and related_bhs But he is not going to work on it for 2.4" . Mike replied, "Yes, I read this one when it was posted, but forgot the details. It seems that inode-highmem is relatively self contained though."

9. Linus Comments On Some Specifics Of The SCO Case

22 Dec 2003 (5 posts) Archive Link: "hmm.."

Topics: BSD, Ioctls, Microkernels

People: John DeeLinus Torvalds

John Dee said, "I know you guys have already probably seen this.. figured I'd share with the class, so the big kids can tear it apart." . Linus Torvalds replied:

I spent half an hour tearing part of it apart for some journalists. No guarantees for the full accuracy of this write-up, and in particular I don't actually have "original UNIX" code to compare against, but the files I checked (ctype.[ch]) definitely do not have any UNIX history to them.

The rest of the files are mostly errno.h/signal.h/ioctl.h (and they are apparently the 2.4.x versions, before we moved some common constants into "asm-generic/errno.h"), and while I haven't analyzed them, I know for a fact that

So to me it looks like

(Later, non-x86 architectures have tried harder to be binary-compatible with their "real UNIX" counter-parts, and as a result we have different errno header files for different architectures - and on non-x86 architectures the numbers will usually match traditional UNIX).

For example, doing a "grep" for SIGBUS on the kernel shows that most architectures still have SIGBUS at 7 (original Linux value), while alpha, sparc, parisc and mips have it at 10 (to match "real UNIX").

What this tells me is that the original code never came from UNIX, but some architectures later were made to use the same values as UNIX for binary compatibility (I know this is true for alpha, for example: being compatible with OSF/1 was one of my very early goals in that port).

In other words, I think we can totally _demolish_ the SCO claim that these 65 files were somehow "copied". They clearly are not.

Which should come as no surprise to people. But I think it's nice to see just _how_ clearly we can show that SCO is - yet again - totally incorrect.


For example, SCO lists the files "include/linux/ctype.h" and "lib/ctype.h", and some trivial digging shows that those files are actually there in the original 0.01 distribution of Linux (ie September of 1991). And I can state

In short: for the files where I personally checked the history, I can definitely say that those files are trivially written by me personally, with no copying from any UNIX code _ever_.

So it's definitely not a question of "all derivative branches". It's a question of the fact that I can show (and SCO should have been able to see) that the list they show clearly shows original work, not "copied".

Analysis of "lib/ctype.c" and "include/linux/ctype.h".

First, some background: the "ctype" name comes "character type", and the whole point of "ctype.h" and "ctype.c" is to test what kind of character we're dealing with. In other words, those files implement tests for doing things like asking "is this character a digit" or "is this character an uppercase letter" etc. So you can write thing like

        if (isdigit(c)) {
                .. we do something with the digit ..

and the ctype files implement that logic.

Those files exist (in very similar form) in the original Linux-0.01 release under the names "lib/ctype.c" and "include/ctype.h". That kernel was released in September of 1991, and contains no code except for mine (and Lars Wirzenius, who co-wrote "kernel/vsprintf.c").

In fact, you can look at the files today and 12 years ago, and you can see clearly that they are largely the same: the modern files have been cleaned up and fix a number of really ugly things (tolower/toupper works properly), but they are clearly incremental improvement on the original one.

And the original one does NOT look like the unix source one. It has several similarities, but they are clearly due to:

The above things basically explain the similarities. There simply aren't that many ways to do a standard C "ctype" implementation, in other words.

Now, let's look at the _differences_ in Linux and traditional UNIX:

Basically, the above is _exactly_ the kinds of mistakes a young programmer would make. It's classic.

And I bet it's _not_ what the UNIX code looked like, even in 1991. UNIX by then was 20 years old, and I _think_ that it uses a simple table lookup (which makes a lot more sense anyway and solves all problems). I'd be very susprised if it had those kinds of "beginner mistakes" in it, but I don't actually have access to the code, so what do I know? (I can look up some BSD code on the web, it definitely does _not_ do anythign like the above).

The lack of proper parenthesis exists in other places of the original Linux ctype.h file too: isascii() and toascii() are similarly broken.

In other words: there are _lots_ of indications that the code was not copied, but was written from scratch. Bugs and all.

Oh, another detail: try searching the web (google is your friend) for "_ctmp". It's unique enough that you'll notice that all the returned hits are all Linux-related. No UNIX hits anywhere. Doing a google for

_ctmp -linux

shows more Linux pages (that just don't happen to have "linux" in them), except for one which is the L4 microkernel, and that one shows that they used the Linux header file (it still says "_LINUX_CTYPE_H" in it).

So there is definitely a lot of proof that my ctype.h is original work.

10. Status Of OOM Killer In 2.4

22 Dec 2003 - 28 Dec 2003 (2 posts) Archive Link: "Finding a user space alternative to the (removed) OOM killer"

Topics: OOM Killer

People: Marcelo Tosatti

Anders Torger noticed that the out-of-memory (OOM) killer had been removed from the 2.4 kernel, and asked if there were a user-space alternative he could use. Marcelo Tosatti replied, "2.4.24-pre1 re-adds the OOM killer as a configurable option. 2.4.24-pre1 with CONFIG_OOM_KILLER=y will work for you."

11. Cryptoloop To Be Deprecated In Favor Of dm-crypt In 2.6

22 Dec 2003 - 23 Dec 2003 (23 posts) Archive Link: "loop driver, device-mapper and crypto"

Topics: Device Mapper

People: Christophe SaoutAndrew MortonFruhwirth Clemens

Christophe Saout said:

there are problems with the loop driver in the kernel with block device backing.

In 2.6 we have a device-mapper which does such things in a much more generic way. I've already talked to a bunch of people working on loop and cryptoloop (also with Clemens Fruhwirth, the cryptoloop maintainer) and they all agreed that device-mapper is probably the most correct way to go, and would be happier if the loop driver was used for files only.

I've written a device-mapper target "dm-crypt" some month ago which uses cryptoapi and is compatible with cryptoloop. I never got much feedback, some people tested it and found it to work just fine while cryptoloop didn't, back then, when the test-series started or so.

Unfortunately I never got much public support on LKML itself and was mostly ignored.

Andrew Morton replied:

I'm not a crypto-loop user, so I am not in a position to judge whether using dm for crypto-on-disk is feature-sufficient and adequate from an operational point of view.

It is good that Joe-and-co are OK with it and are prepared to help support it. If the people who _do_ use crypto-loop like the look of the feature set and the user interface then fine. Certainly the loop driver has a long history of not working very well.

So. If those-in-the-know like it then go wild. It would be useful to get an opinion from the distro guys too.

However I suspect that there will be a migration issue, and that we should continue to work to get crypto-loop functioning well, plan to remove it from 2.8, yes?

And Fruhwirth Clemens said:

First of all, eventhou I'm the maintainer of cryptoloop, when Christophe posted the first time I immediately recognized that dm-crypt is vastly superior to cryptoloop for a number of reasons:

From an operational point of view, patching util-linux has been the most troublesome point. Lot's of incompatible inofficial patches floating around in the net, while the last release of util-linux provides a broken and IMHO insecure why of setting up cryptokeys. Further: To fix the design flaw of unencrypted/unhashed IV vectors one has to add another setup parameter. That's where I really do like the flexible interface dm has.

He added, "We should support cryptoloop. No new features, but working well. At the same time we should declare it 'deprecated' and provide dm-crypt as alternative. I'm happy to provide documentation on how to migrate" .

12. Marcelo On Christmas Break

22 Dec 2003 (1 post) Archive Link: "Out for Christmas"

People: Marcelo Tosatti

Marcelo Tosatti said he'd be away for Christmas, and would be back December 27.

13. forcedeth Version 0.20 Released

22 Dec 2003 (1 post) Archive Link: "forcedeth: version 0.20 available"

People: Carl-Daniel Hailfinger

Carl-Daniel Hailfinger announced:

version 0.20 of forcedeth (GPLed nvnet replacement for nForce on-board nics) for Linux 2.4 and 2.6 is available at It is also integrated in current -mm patchset and the 2.6 experimental net driver queue.

I will make precompiled modules available at the above address as time permits.

Fixes in this release over 0.18:

Known issues:

14. udev Version 010 Released

22 Dec 2003 (2 posts) Archive Link: "[ANNOUNCE] udev 010 release"

Topics: Disks: IDE, FS: devfs, FS: sysfs, Hot-Plugging, Version Control

People: Greg KH

Greg KH announced:

I've released the 010 version of udev. It can be found at:

rpms built against Red Hat FC1 are available at:
with the source rpm at:

udev is a implementation of devfs in userspace using sysfs and /sbin/hotplug. It requires a 2.6 kernel to run. Please see the udev FAQ for any questions about it:

Please read the FAQ if you have any questions about devfs and udev. It's been updated a lot in response to all of the confusion about this topic.

The major changes since the 008 release are:

Thanks again to everyone who has send me patches for this release, a full list of everyone, and their changes is below.

udev development is done in a BitKeeper repository located at:

Daily snapshots of this tree used to be found at:
But that box seems to be down now. Hopefully it will be restored someday. If anyone ever wants a tarball of the current bk tree, just email me.

He added in reply to himself:

Oh, forgot to mention that udev runs a _lot_ slower now, taking at least 1 second for every device addition. This makes the initscript or the test scripts take a long time.

This was done to try to fix the race condition where udev beats the kernel before it has created all of the sysfs links and files. I need some libsysfs changes before this can be done properly, without the big speed hit (the libsysfs people are working on it.)

If anyone's interested in it, take a look at the FIXMEs in namedev.c. I tried messing around with just a simple stat() call, but still couldn't reliably get stuff to work for partitions on usb-storage devices (which are slow to enumerate.) Any help here would be apprecated.

15. Support For Hot-Swapping RAM

22 Dec 2003 (1 post) Archive Link: "Memory Hot add prototye patch v0.1"

Topics: Big Memory Support, Hot-Plugging, Power Management: ACPI

People: Yasunori Goto

Yasunori Goto said:

This is a Memory hot-add prototype patch against linux-2.6.0.

My target is a machine which has multi-node like NUMA. So, I assume a situation that a node which has memory is hot-added. I use the idea of multi-node emulation from Iwamoto-san's hot-remove patch. (

To hot-add memory, please execute following command.
$ echo "enable <number of node>" > /proc/memhotplug

TODO list is followings.

16. 2.6.0-mm1 Released

22 Dec 2003 - 28 Dec 2003 (59 posts) Archive Link: "2.6.0-mm1"

Topics: Kernel Release Announcement

People: Andrew MortonChristoph Hellwig

Andrew Morton announced 2.6.0-mm1, saying, "Quite a lot of new material here. It would be appreciated if people who have significant patches in -mm could retest please." There was quite a bit of discussion, as folks pounded on the release; as part of the general attack, Christoph Hellwig also asked, "BTW, could you please drop Al's" [Viro] " RD* patches? They change the entry points for block drivers and thus create some hassle for people hacking on out of tree block drivers, and obviously can't go into mainline as is." Andrew replied, "Have you discussed this with him? I was actually hoping to get those patches merged up soon." Christoph replied, "A while ago he said he's gonna redo those parts that don't change the API for 2.6 and will postpone the rest to 2.7."

17. Ian Kent New DevFS Maintainer

23 Dec 2003 - 25 Dec 2003 (34 posts) Archive Link: "Re: DevFS vs. udev"

Topics: FS: devfs, FS: ramfs, FS: sysfs

People: Ian KentAndrew MortonAlexander ViroAndrey BorzenkovRobert LoveGreg KH

Bradley W. Allen started a DevFS vs. udev flamewar by saying he thought DevFS was fine and should be kept. Amid the general tumult, Greg KH asked if Bradley was volunteering to maintain DevFS; and Ian Kent said he'd be willing to do that. But he added, "However, if Andrew wants it gone from the kernel there is no point." Andrew Morton replied:

I do not. devfs shall remain in 2.6 and shall continue to be supported.

Richard has disappeared but Andrey Borzenkov understands devfs well and performed valuable work on it during 2.5 development.

Nor would I recommend that devfs be removed early from 2.7.x. We should wait until the proposed udev/sysfs solutions have matured in 2.6 and have proven themselves in the field. Only then will we be in a position to confirm that devfs can be removed without causing some people unacceptable levels of grief. There is no rush.

And yes, there are architectural/cleanliness issues with devfs. In 2.5 Adam Richter totally reinventing devfs's internals, basing it around the ramfs infrastructure. If we elect to retain devfs in 2.8 then that effort should be resurrected.

Now would be a good time for someone to feed the whole thing through indent though.

Alexander Viro replied, "Switching internals to ramfs won't be enough, though. There are problems with devfs API that can't be solved by work on internals - lifetime rules for devfs nodes make no sense. Take a look at the insertion/removal primitives and think of the lifetime rules they create for directories and user-created nodes. _That_ is independent from the way you implement the internals (and sanitized version of the interface won't fit into use of ramfs, BTW)." Elsewhere, Robert Love tried to warn Ian that DevFS maintainership would be a living nightmare; but Ian stood firm.

18. Status Of laptop-mode Patch For 2.6

23 Dec 2003 (3 posts) Archive Link: "Attempt at laptop-mode for 2.6.0"

Topics: FS: ext3, FS: sysfs, Spam, Virtual Memory

People: Bart SamwelJens Axboe

Bart Samwel said:

Even though I don't own a laptop, I find it very irritating that my hard drive is active so much. Wanting to fix this, I found the Jens Axboe's "laptop-mode" patch. Unfortunately it hadn't been ported to Linux 2.6.0 yet, and I'm using that as my primary kernel now. I gave porting it a shot, and here is the result. I'm running it right now, and my hard drive has been spun down for the complete time I have been writing this message. Still, I'm not sure whether it really works as advertised. :) The reason is that my PC is also a mail server for my personal e-mail, and I receive e-mails more than once every 10 minutes (fscking spam!). Still, the tests that I've done seem to indicate that it works.

I've done some things differently than in Jens's patch (my port is based on v4 of the patch BTW):

Disclaimer: I'm not a very experienced kernel developer, and I may have made mistakes. Don't kill me if it doesn't work. :) I'd appreciate some feedback, so if it works or doesn't work for you, please let me know!

Jens Axboe replied:

Thanks for getting this started. I'm not particularly fond of the behaviourial changes you made, I guess most are due to it being incomplete?

The block dirtying is the most interesting aspect of the dump functionality, reporting WRITEs don't give you the info you need to fix your setup.

Bart said, "that depends on your point of view. At this point it weren't the WRITEs that were interesting to me, it were the READs. The WRITEs just came as a bonus. The reason: what bugged me during development were the programs that read new data from disk, and I wanted to find out what to turn off in order to keep the disk from spinning up all the time. And when the disk DID spin up, I wanted to know if it was my fault or if it was some daemon messing up my tests again. This is due to my not actually working on a laptop but on a home server machine. :) I guess that when you're going for disk-spindowns of longer than 10 minutes (which is what the block dirtying dumps are for, presumably?) dirtyings start to become interesting. I'll see if I can port that bit as well, shouldn't be that much work."

19. Scheduler Documentation

24 Dec 2003 (6 posts) Archive Link: "linux kernel scheduler"

People: Jason PachecoRobert Love

Someone asked for documentation on the Linux kernel scheduler, and Jason Pacheco replied, "I recently purchased "Linux Kernel Development" by Robert Love. I haven't finished it yet, but so far I would give it great reviews. It has a very simple style and is easy to understand. The book solely covers the 2.6 kernel and explains where it differentiates from the earlier kernels. Chapter 3 is dedicated to Scheduling and will give you all the information you need as far as how the 2.6 kernel does scheduling. For the 2.4 kernel there is plenty of documentation available on that already."

20. 2.6.0-tiny1 Released

27 Dec 2003 - 28 Dec 2003 (4 posts) Archive Link: "[ANNOUNCE] 2.6.0-tiny1 tree for small systems"

Topics: Networking, Small Systems

People: Matt MackallMike FedykWilliam Lee Irwin IIIJeff Garzik

Matt Mackall announced:

This is the second release of the -tiny kernel tree. The aim of this tree is to collect patches that reduce kernel disk and memory footprint as well as tools for working on small systems. Target users are things like embedded systems, small or legacy desktop folks, and handhelds.

Latest release includes:

Thanks to Holger Shuring, Bill Irwin, and Zwane Mwaikamba for sending me various tweaks.

The patch, currently against 2.6.0, can be found at:

Mike Fedyk suggested, "Maybe wli will be interested in this one since he has some stack shrinking patches in his tree..." And William Lee Irwin III replied, "I'm already following this in general. I contributed a number of fixes I've done for the 4K stack code over time at the time mpm originally put -tiny together, though I think he's rearranged various things (e.g. re-split the thing into 3 pieces) I can't be arsed to deal with."







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.