Kernel Traffic #247 For 31 Dec 2003 By Zack Brown Table Of Contents * Standard Format * Text Format * XML Source * Czech Translation * Threads Covered 1. 18 Dec 2003 - 21 Dec 2003 (15 Status Of "Linux Device Drivers" posts) 2. 18 Dec 2003 - 22 Dec 2003 (27 Patent-Encumbered Code Explicitly posts) Rejected From Linux 3. 18 Dec 2003 - 21 Dec 2003 (13 Real-Time Maintainership; Nanokernel posts) Maintainership; Patent Policy 4. 19 Dec 2003 - 20 Dec 2003 (2 Using Distcc With 2.6 posts) 5. 20 Dec 2003 - 22 Dec 2003 (5 Status Of Large Filesystem Support posts) 6. 21 Dec 2003 (1 perfctr-2.6.3 Released post) 7. 23 Dec 2003 (1 Larry Unsubscribes From linux-kernel post) Mailing List 8. 22 Dec 2003 - 23 Dec 2003 (7 Linux 2.4.24-pre2 Released posts) 9. 22 Dec 2003 (5 Linus Comments On Some Specifics Of posts) The SCO Case 10. 22 Dec 2003 - 28 Dec 2003 (2 Status Of OOM Killer In 2.4 posts) 11. 22 Dec 2003 - 23 Dec 2003 (23 Cryptoloop To Be Deprecated In Favor posts) Of dm-crypt In 2.6 12. 22 Dec 2003 (1 Marcelo On Christmas Break post) 13. 22 Dec 2003 (1 forcedeth Version 0.20 Released post) 14. 22 Dec 2003 (2 udev Version 010 Released posts) 15. 22 Dec 2003 (1 Support For Hot-Swapping RAM post) 16. 22 Dec 2003 - 28 Dec 2003 (59 2.6.0-mm1 Released posts) 17. 23 Dec 2003 - 25 Dec 2003 (34 Ian Kent New DevFS Maintainer posts) 18. 23 Dec 2003 (3 Status Of laptop-mode Patch For 2.6 posts) 19. 24 Dec 2003 (6 Scheduler Documentation posts) 20. 27 Dec 2003 - 28 Dec 2003 (4 2.6.0-tiny1 Released posts) 1. Status Of "Linux Device Drivers" 18 Dec 2003 - 21 Dec 2003 (15 posts) Archive Link: "Linux Device Drivers 3rd Edition" People: Jonathan Corbet, Xavier Bestel, Jose 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 (http://lwn.net/Articles/driver-porting /) ; 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 Buytenhek, Linus Torvalds, Adrian 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. http://mpeg4ip.sourceforge.net/ 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 Mwaikambo, Karim Yaghmour, Nick Piggin, Linus Torvalds, Larry McVoy, Philippe Gerum, Joern Engel, Victor 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, rtlinux.org is only an alias for fsmlabs.com, 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 (http://www.ussg.iu.edu/hypermail/linux/kernel/0312.2/ 0624.html). Second, "RTLinux Free" is being ported over to Adeos (http:// www2.fsmlabs.com/pipermail/rtl/2003-December/013178.html). 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 Brow, Tomas 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 Amon, Jose Luis Domingo Lopez, Peter 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: http:// www.suse.de/~aj/linux_lfs.html 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 http://www.gelato.unsw.edu.au/IA64wiki/LargeBlockDevices 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 Pettersson, Pavel Machek Mikael Pettersson announced: Version 2.6.3 of perfctr, the Linux/x86 performance monitoring counters driver, is now available at the usual place: http://www.csd.uu.se/~mikpe/linux/perfctr/ Version 2.6.3, 2003-12-21 * Fixed a bug where a read of the global-mode counters could fail with EOVERFLOW due to an incorrect structure descriptor. The bug only existed in perfctr-2.6.2. (Thanks to Pavel Machek for reporting this problem.) * AMD64 IA32 emulation code cleaned up for kernel 2.4.23. * Updated kernel support: 2.6.0, 2.4.24-pre1, 2.4.23, 2.4.22-1.2129.nptl (FC1 update), 2.4.21-1.1931.2.393.ent (RHEL Taroon beta), and 2.4.20-24 (RH 7.x/ 8/9 update). * User-space package rpm spec file fixes: + Don't remove /dev/perfctr on package uninstall. + Don't add alias to /etc/modules.conf if it's already there. 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 McVoy, Zack 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 (http://gnuarch.org/bin/view) 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 Tosatti, Mike Fedyk, Xose 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 (http://marc.theaimsgroup.com/?l=linux-kernel&m=107048611507709&w=2) 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 Dee, Linus 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. http://lwn.net/ Articles/64052/" . 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 * the original errno.h used different error numbers than "original UNIX" I know this because I cursed it later when it meant that doing things like binary emulation wasn't as trivial - you had to translate the error numbers. * same goes for "signal.h": while a lot of the standard signals are well documented (ie "SIGKILL is 9"), historically we had lots of confusion (ie I think "real UNIX" has SIGBUS at 10, while Linux didn't originally have any SIGBUS at all, and later put it at 7 which was originally SIGUNUSED. So to me it looks like * yes, Linux obviously has the same signal names and error number names that UNIX has (so the files certainly have a lot of the same identifiers) * but equally clearly they weren't copied from any "real UNIX". (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. Linus 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 * I wrote them (and looking at the original ones, I'm a bit ashamed: the "toupper()" and "tolower()" macros are so horribly ugly that I wouldn't admit to writing them if it wasn't because somebody else claimed to have done so ;) * writing them is no more than five minutes of work (you can verify that with any C programmer, so you don't have to take my word for it) * the details in them aren't even the same as in the BSD/UNIX files (the approach is the same, but if you look at actual implementation details you will notice that it's not just that my original "tolower/toupper" were embarrassingly ugly, a number of other details differ too). 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 "ctype" interfaces are defined by the C standard library. * the C standard also specifies what kinds of names a system library interface can use internally. In particular, the C standard specifies that names that start with an underscore and a capital letter are "internal" to the library. This is important, because it explains why both the Linux implementation _and_ the UNIX implementation used a particular naming scheme for the flags. * algorithmically, there aren't that many ways to test whether a character is a number or not. That's _especially_ true in C, where a macro must not use it's argument more than once. So for example, the "obvious" implementation of "isdigit()" (which tests for whether a character is a digit or not) would be #define isdigit(x) ((x) >= '0' && (x) <= '9') but this is not actually allowed by the C standard (because 'x' is used twice). This explains why both Linux and traditional UNIX use the "other" obvious implementation: having an array that describes what each of the possible 256 characters are, and testing the contents of that array (indexed by the character) instead. That way the macro argument is only used once. 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: * both Linux and traditional unix use a naming scheme of "underscore and a capital letter" for the flag names. There are flags for "is upper case" (_U) and "is lower case" (_L), and surprise surprise, both UNIX and Linux use the same name. But think about it - if you wanted to use a short flag name, and you were limited by the C standard naming, what names _would_ you use? Maybe you'd select "U" for "Upper case" and "L" for "Lower case"? Looking at the other flags, Linux uses "_D" for "Digit", while traditional UNIX instead uses "_N" for "Number". Both make sense, but they are different. I personally think that the Linux naming makes more sense (the function that tests for a digit is called "isdigit()", not "isnumber()"), but on the other hand I can certainly understand why UNIX uses "_N" - the function that checs for whether a character is "alphanumeric" is called "isalnum()", and that checks whether the character is a upper case letter, a lower-case letter _or_ a digit (aka "number"). In short: there aren't that many ways you can choose the names, and there is lots of overlap, but it's clearly not 100%. * The original Linux ctype.h/ctype.c file has obvious deficiencies, which pretty much point to somebody new to C making mistakes (me) rather than any old and respected source. For example, the "toupper()/tolower()" macros are just totally broken, and nobody would write the "isascii()" and "toascii()" the way they were written in that original Linux. And you can see that they got fixed later on in Linux development, even though you can also see that the files otherwise didn't change. For example: remember how C macros must only use their argument once (never mind why - you really don't care, so just take it on faith, for now). So let's say that you wanted to change an upper case character into a lower case one, which is what "tolower()" does. Normal use is just a fairly obvious newchar = tolower(oldchar); and the original Linux code does extern char _ctmp; #define tolower(c) (_ctmp=c,isupper(_ctmp)?_ctmp+('a'+'A'):_ctmp) which is not very pretty, but notice how we have a "temporary character" _ctmp (remember that internal header names should start with an underscore and an upper case character - this is already slightly broken in itself). That's there so that we can use the argument "c" only once - to assign it to the new temporary - and then later on we use that temporary several times. Now, the reason this is broken is + it's not thread-safe (if two different threads try to do this at once, they will stomp on each others temporary variable) + the argument (c) might be a complex expression, and as such it should really be parenthesized. The above gets several valid (but unusual) expressions wrong. 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 Saout, Andrew Morton, Fruhwirth 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: * It does not suffer from loop.c bugs (There are a lot, no maintainer) * dm-crypt does not depend on special user space tool (util-linux) * dm-crypt uses mempool, which makes it rock stable compared to cryptoloop. 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 http://www.hailfinger.org/carldani/linux/ patches/forcedeth/. 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: * Work around bogus MAC addresses. Please report your exact hardware version/ manufacturer if you hit this issue since NVidia has stated this should never happen and they are interested in any cases where it happens. * Under extremely high network load on nForce3 systems, the nic won't lock up or slow down any more. Known issues: * Some nForce versions will report every received packet as 1500 bytes long and fool RX statistics. This is definitely a hardware bug and we intend to provide a workaround in v0.21 * nForce3 systems are programmed to an incredibly high interrupt rate. We still need to find out what value to write to the timer register and we intend to fix this in v0.21 * "eth0: received irq with unknown events 0x. Please report" might show up in your logs. That means we didn't encounter such an event during development and can only guess about its meaning. Please tell us what you were doing when the message appeared, how often it appeared and if it affects behaviour of your machine negatively. 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: kernel.org/pub/linux/utils/kernel/hotplug/udev-010.tar.gz (http:// www.kernel.org/pub/linux/utils/kernel/hotplug/udev-010.tar.gz) rpms built against Red Hat FC1 are available at: kernel.org/pub/linux/utils/kernel/hotplug/udev-010-1.i386.rpm (http:// www.kernel.org/pub/linux/utils/kernel/hotplug/udev-010-1.i386.rpm) with the source rpm at: kernel.org/pub/linux/utils/kernel/hotplug/udev-010-1.src.rpm 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: kernel.org/pub/linux/utils/kernel/hotplug/udev-FAQ (http://www.kernel.org/pub/ linux/utils/kernel/hotplug/udev-FAQ) 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: * a number of bugs that were in the 009 release are now fixed. The extras/ subdir should now build properly (but I take no responsibility if it doesn't...) * we now don't blow away old config files if you install this version on top of an older version. Sorry about that... * udev now supports looking at multiple sysfs files at once for a single rule. This enables you to write such rules as: LABEL, BUS="usb", SYSFS_vendor="FUJIFILM", SYSFS_model="M100", NAME="camera%n" which helps in trying to identify a device in a unique way. Right now udev supports up to 5 different sysfs files. If you want to have more, the code can be changed, just let me know. * new format modifier "%k" has been added to allow rules to use the kernel name of the device. * an example shell script that handles an IDE devfs mapping has been added to the tarball. Thanks to Kay Sievers for this. 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: bk://linuxusb.bkbits.net/udev Daily snapshots of this tree used to be found at: http://www.codemonkey.org.uk/projects/bitkeeper/udev/ 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. (http://marc.theaimsgroup.com/?l =linux-kernel&m=107025023221904&w=2) * Hot-added memory is used for highmem in this patch. * A node has only 1 contiguous memory block. * kswapd should be executed for added node, but not yet. To hot-add memory, please execute following command. $ echo "enable " > /proc/memhotplug TODO list is followings. * Port to IA64. (It is real target for me. But IA32 code is good for investigation of generic way, and many person can try to use it.) * Using SRAT table of ACPI to recognize multinode. * There might be some useful parts in memory hotadd project's patch. (http:// sourceforge.net/projects/linux-memhotadd/) * The case that node has some discontiguous memory block. ( Should I use CONFIG_NONLINEAR? But, I don't have idea how to map the hole address of hot-removed memory by this configuration yet. If you have good idea, I'm glad.) * etc. (it's a lot. ;-) ) 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 Morton, Christoph 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 Kent, Andrew Morton, Alexander Viro, Andrey Borzenkov, Robert Love , Greg 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 Samwel, Jens 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): * The block dirtying reporting is not there. As an alternative, you can write a number N higher than 1 into /proc/sys/vm/laptop_mode, which will give you reports on N-1 actual read/write operations, including the pid+command that caused them. This gives you a way to put a reasonable bound on the number of messages you're going to get. You're only interested in the first one (the one that spins up your disk) anyway. The messages look like this: ll_rw_block: (107 reports left) READ requested by imapd (pid 1137) * When laptop mode is on, wb_kupdate() also performs all of the other actions mentioned in do_sync(). I don't know whether this is really necessary because I don't know the full implications of all those actions, but at least it REALLY makes sure that everything is synced. * The script writes to different values in /proc/sys/vm, because the Linux 2.6 VM has different controls. * The patch does not modify the ext3 journal commit timeout; you have to mount your filesystem with commit=600 (or whatever your preferred value is) to get the correct effect. The 2.4 patch modified the expiration of an ext3 transaction, I've removed this as I don't see the use if you're going to have to mount the fs with "commit=" anyway. The default expiration time of an ext3 transaction is equal to the commit interval, which is very reasonable. Usually you'd set your commit interval to the same as the dirty_writeback_centisecs value (in seconds, then), so it would boil down to the same thing. 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 Pacheco, Robert Love Someone asked for documentation on the Linux kernel scheduler, and Jason Pacheco replied, "I recently purchased "Linux Kernel Development (http:// www.bookfinder.com/search/?author=Robert+Love&title=Linux+Kernel&st=xl&ac=qr) " 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 Mackall, Mike Fedyk, William Lee Irwin III, Jeff 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: * sync against 2.6.0 * fix for CONFIG_SYSCTL compilation * Jeff Garzik's netdrvr patchkit, along with latest netpoll/netconsole code * kgdb and kgdb-over-ethernet debugging support * "make checkstack" to find largest stack users * script to estimate actual code size of inline functions (experimental) * some other minor new tweaks 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: http://selenic.com/tiny/2.6.0-tiny1.patch.bz2 http://selenic.com/tiny/2.6.0-tiny1-broken-out.tar.bz2 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 kernel.org. All pages on this site are copyright their original authors, and distributed under the terms of the GNU General Public License version 2.0.