Kernel Traffic #70 For 5 Jun 2000

By Zack Brown

Table Of Contents

Mailing List Stats For This Week

We looked at 1084 posts in 4517K.

There were 419 different contributors. 180 posted more than once. 128 posted last week too.

The top posters of the week were:

1. Linux On Hand Calculators

16 May 2000 - 24 May 2000 (21 posts) Archive Link: "Linux on the TI-89/92[+]???"

Topics: Assembly

People: Kenneth C. ArnoldVojtech PavlikWilliam AstleAndrew McNabbDaniel EggerDr. Kelsey HudsonPavel Machek

Kenneth C. Arnold asked, "since Linux supports the M68k family down to the M68020 last I checked, would it be _even remotely possible_ to do a port to the TI-89 / TI-92[+], which are graphing calculators based on the M68000?" Vojtech Pavlik was optimistic, replying, "I think the TI-92+ (preferably 3x overclocked, too) should be able to run uCLinux quite OK. Enough flash (1 MB) for read only root filesystem, enough ram (640 KB) for running the OS - not as good as the PalmPilots, but it could fit in there."

Dr. Kelsey Hudson first thought that those calculators used the 16-bit 6809, not the 32-bit 68K. (William Astle emails me privately to add,

The 6809 chip is an 8 bit CPU with a 16 bit address space.
-- Ed: [05 Jun 2000 11:30:00 -0800] But he replied to himself (and others pointed out) that no, they did in fact use the 68K. As evidence, Kenneth gave a pointer to a TI-89/92 Plus Assembly Programming ( page, and another page ( that was unreachable by KT press time.

Elsewhere, Andrew McNabb was doubtful that anything could be done to get Linux on those machines. He explained, "Linux only works on Mac II's (which have 68020's) that have a certain MMU. I imagine that as you go to a 68000, even more stuff will be fouled up. There are also major issues about I/O, installation, etc. I think that trying to port to a TI would be a waste of time." But Daniel Egger replied that 'uLinux' would run on systems without memory management units (MMUs), and added, "even a port to the dragonball (a CPU with Motorola 68000 core and embedded connectivity) exists and is running fine for me." Kenneth asked for some pointers to documentation describing the differences between the dragonball and the M68000, and Daniel gave him a pointer to MC68328: DragonBall[tm] Integrated Microprocessor (,1250,MC68328~M934310090795,00.html) .

Pavel Machek felt that the TI-92 was really not that interesting, and a fairly pointless goal for a Linux port. Vojtech replied simply, "TI92 is cheap, has clock up to 25 MHz, and runs half a year on four AA batteries ..."

2. Things To Do Before 2.4: Saga Continues

18 May 2000 - 28 May 2000 (89 posts) Archive Link: "Linux 2.3.99pre9-2 JOB list"

Topics: Compression, Disk Arrays: RAID, Disks: IDE, Disks: SCSI, FS: FAT, FS: NFS, FS: NTFS, FS: UMSDOS, I2O, Networking, PCI, Power Management: ACPI, Real-Time, SMP, Samba, Security, USB, Virtual Memory, VisWS

People: Alan CoxCraig KulesaRik van RielDavid FordAlexander ViroJeff GarzikVojtech PavlikChristopher ThompsonMartin MaresAndrea ArcangeliJuan J. QuintelaBen Collins

Alan Cox posted the latest in his series of lists of things to do before 2.4 could come out. For the last one, see Issue #66, Section #5  (24 Apr 2000: To Do Before 2.4: Saga Continues) . This week, he listed:

  1. Fixed

    1. Tulip hang on rmmod (fixed in .51 ?)
    2. Incredibly slow loopback tcp bug (believed fixed about 2.3.48)
    3. COMX series WAN now merged
    4. VM needs rebalancing or we have a bad leak
    5. SHM works chroot
    6. SHM back compatibility
    7. Intel i960 problems with I2O
    8. Symbol clashes and other mess from _three_ copies of zlib!
    9. PCI buffer overruns
    10. Shared memory changes change the API breaking applications (eg gimp)
    11. Finish softnet driver port over and cleanups
    12. via rhine oopses under load ?
    13. SCSI generic driver crashes controllers (need to pass PCI_DIR_UNKNOWN..)
    14. UMSDOS fixups resync (not quite done)
    15. Make NTFS sort of work
    16. Any user can crash FAT fs code with ftruncate
    17. AFFS fixups
    18. Directory race fix for UFS
    19. Security holes in execve()
    20. Lan Media WAN update for 2.3
    21. Get the Emu10K merged
    22. Paride seems to need fixes for the block changes yet
    23. Kernel corrupts fs and gs in some situations (Ulrich has demo code)
    24. 1.07 AMI MegaRAID
    25. Merge 2.2.15 changes (Alan)
    26. Get RAID 0.90 in (Ingo)
    27. S/390 Merge
    28. NFS DoS fix (security)
    29. Merge the RIO driver
    30. Fix Space.c duplicate string/write to constants
    31. Elevator and block handling queue change errors are all sorted
    32. Fix all remaining PCI code to use new resources and enable_Device
    33. Make sure all drivers return 1 from their __setup functions (Done ?)
    34. Enhanced disk statistics

  2. In Progress

    1. Merge the network fixes (DaveM)
    2. Finish I2O merge (Intel/Alan)
    3. Complete vfsmount merge (Al Viro)
    4. Merge removed-buf-open directory stuff into VFS (Al Viro)
    5. vmalloc(GFP_DMA) is needed for DMA drivers (Ingo)

  3. Fix Exists In -AC Tree

    1. Signals leak kernel memory (security)

  4. Fix Exists But Isnt Merged

    1. msync fails on NFS (probably fixed anyway)
    2. Semaphore races (fix in 2.2)
    3. Semaphore memory leak (fix in 2.2)
    4. Exploitable leak in file locking (Willy)
    5. Mark SGI VisWS obsolete
    6. 64bit lockf support
    7. TTY and N_HDLC layer called poll_wait twice per fd and corrupt memory
    8. ATM layer calls poll_wait twice per fd and corrupts memory
    9. Random calls poll_wait twice per fd and corrupts memory
    10. PCI sound calls poll_wait twice per fd and corrupts memory
    11. sbus audio calls poll_wait twice per fd and corrupts memory
    12. Support MP table above 1Gig (Ingo)
    13. Finish sorting out VM balancing (Rik Van Riel)
    14. access_process_mm oops/lockup if task->mm changes (Manfred)
    15. Dont panic on boot when meeting HP boxes with wacked APIC table numbering (AC)
    16. SMP affinity code creates multiple dirs with the same name (Ingo)
    17. Scheduler bugs in RT (Dimitris)
    18. TLB flush should use highest priority (Ingo)
    19. Set SMP affinity mask to actual cpu online mask (needed for some boards) (Ingo)
    20. Fix eth= command line
    21. HFS is still broken
    22. AIC7xxx doesnt work non PCI ? (Doug says OK, new version due anyway)
    23. 8139 + bridging fails

  5. Security

    1. put_user is broken for i386 machines (security) - sem stuff may be wrong too
    2. Fix module remove race bug (mostly done - Al Viro)

  6. To Do

    1. IDE fails on some VIA boards (eg the i-opener)
    2. Find out what has ruined disk I/O throughput.
    3. Restore O_SYNC functionality
    4. Trace numerous random crashes in the inode cache
    5. VM kswapd has some serious problems
    6. Test other file systems on write
    7. Audit all char and block drivers to ensure they are safe with the 2.3 locking - a lot of them are not especially on the open() path.
    8. Stick lock_kernel() calls around driver with issues to hard to fix nicely for 2.4 itself
    9. PCMCIA/Cardbus hangs, IRQ problems, Keyboard/mouse problem (may be fixed ?)
    10. Use PCI DMA by default in IDE is unsafe (must not do so on via VPx x<3)
    11. Use PCI DMA 'lost interrupt' problem with some hw [which ?]
    12. Crashes on boot on some Compaqs ? (may be fixed)
    13. pci_set_master forces a 64 latency on low latency setting devices.Some boards require all cards have latency <= 32
    14. Loopback fs hangs
    15. Problems with ip autoconfig according to Zaitcev
    16. pci_socket crash on unload
    17. truncate_inode_pages does unsafe page cache operations
    18. heavy swapping corrupts ptes
    19. Linux sends a 1K buffer with SCSI inquiries. The ANSI-SCSI limit is 255.
    20. Linux uses TEST_UNIT_READY to chck for device presence on a PUN/LUN. The INQUIRY is the only valid test allowed by the spec.

  7. To Do But Non Showstopper

    1. Make syncppp use new ppp code
    2. Finish 64bit vfs merges (lockf64 and friends missing)
    3. NCR5380 isnt smp safe
    4. DMFE is not SMP safe
    5. ACPI hangs on boot for some systems
    6. Go through as 2.4pre kicks in and figure what we should mark obsolete for the final 2.4
    7. Per Process rtsigio limit
    8. RtSig limit handling bug
    9. Fix SPX socket code
    10. Boot hangs on a range of Dell docking stations (Latitude)
    11. iget abuse in knfsd
    12. Some people report 2.3.x serial problems
    13. USB hangs on APM suspend on some machines
    14. PCMCIA crashes on unloading pci_socket
    15. DEFXX driver appears broken
    16. ISAPnP IRQ handling failing on SB1000 + resource handling bug
    17. TB Multisound driver hasnt been updated for new isa I/O totally.
    18. Fix boards with different TSC per CPU and kill TSC use on them

  8. Compatibility Errors

    1. Xterm broke in 2.3.99pre6 (FIONREAD/select loop)

  9. Probably Post 2.4

    1. per super block write_super needs an async flag
    2. addres_space needs a VM pressure/flush callback (Ingo)
    3. per file_op rw_kiovec

  10. Drivers In 2.2 not 2.4
  11. To Check

    1. Check O_APPEND atomicity bug fixing is complete
    2. Protection on isize (sct) [Al Viro mostly done]
    3. Mikulas claims we need to fix the getblk/mark_buffer_uptodate thing for 2.3.x as well
    4. Network block device seems broken by block device changes
    5. Fbcon races
    6. VFS?VM - mmap/write deadlock (demo code seems to show lock is there)
    7. rw sempahores on page faults (mmap_sem)
    8. kiobuf seperate lock functions/bounce/page_address fixes
    9. Fix routing by fwmark
    10. Some FB drivers check the A000 area and find it busy then bomb out
    11. rw semaphores on inodes to fix read/truncate races ? [Probably fixed]
    12. Not all device drivers are safe now the write inode lock isnt taken on write
    13. File locking needs checking for races
    14. Multiwrite IDE breaks on a disk error [minor issue at best]
    15. ACPI/APM suspend issue - IDE related stuff ?
    16. NFS bugs are fixed
    17. BusLogic crashes when you cat /proc/scsi/BusLogic/0
    18. Floppy last block cache flush error
    19. NFS causes dup kmem_create on reload
    20. Chase reports of SMB not working
    21. exec loader permissions
    22. Locking on getcwd
    23. floppy fails on some machines
    24. IRDA calls get random bytes before random is set up
    25. Some AWE cards are not being found by ISAPnP ??

David Ford replied to several of these items. To item 1.1 (Tulip hang on rmmod (fixed in .51 ?)), he said that no, this was still crashing as of 2.3.99pre3. To item 1.4 (VM needs rebalancing or we have a bad leak), he replied that Andrea Arcangeli's 'classzone' patch fixed it all back up again. Rik van Riel reported that the 'classzone' patch was unstable and incorrect. He suggested Juan J. Quintela's latest patch as attempting to fix the known problems. He and Andrea proceeded to have a brief dispute over the relative merits of various attempts to deal with the recent VM problems. At one point, Craig Kulesa had the last word, "Classzone was presented and discussed extensively on the linux-mm list at the end of April. Start here, follow the thread onwards:"

Elsewhere, Rik replied to Alan's original list, to item 4.13 (Finish sorting out VM balancing (Rik Van Riel)); continuing the credits, he said, "And Juan Quintela and a few other #kernelnewbies folks. The patch seems ready and better than 2.2 or 2.3 has ever been. I'm currently testing stuff and it looks quite good, but as usual beta testers are wanted to see if it works on all workloads. Please try the patch at:" Ben Collins reported good results with the patch, but there was no discussion.

In David's original post, he also suggested as "to do but non-showstopper", "2.3.99-pre9-1, I'm able to mount the floppy any given number of times over and over without unmounting it. No errors seem to happen and umount needs to happen for each mount before the device is no longer in use." Alexander Viro replied, "And that's a bug which way? Yes, we have multiple mounts now. Yes, fs is busy until you undo each mount (obviously). Yes, you can mount over the mountpoint. You are getting precisely what you are asking for - operation used to be illegal, but now it's perfectly OK. So it succeeds. What's the problem?" There was some interest in why such a feature had been added, but no real explanation surfaced. (Stephen Landamore emailed me to point out that this was discussed in Issue #64, Section #9  (14 Apr 2000: More 'devfs' Discussion) . Thanks, Stephen! -- Ed: [06 Jun 2000 23:00:00 -0800]

Also in his original post, to item 6.9 (PCMCIA/Cardbus hangs, IRQ problems, Keyboard/mouse problem (may be fixed ?)), David replied that no, this was nowhere near fixed.

Jeff Garzik also replied to Alan's list. He reported that item 1.32 ("Fix all remaining PCI code to use new resources and enable_Device"), although listed as fixed, was not. Also, item 4.23 ("8139 + bridging fails"), was listed as having a fix that had not been merged. But Jeff said, "a 8139too patch just went to Linus that should fix all issues related to RTL8139 (original) chips." He also pointed out that items 6.16 ("pci_socket crash on unload ") and 7.14 ("PCMCIA crashes on unloading pci_socket") seemed to be identical reports. There was no reply to any of his reports.

Alexander also replied directly to Alan's list, saying that item 2.3 (Complete vfsmount merge (Al Viro)) had been finished.

Vojtech also replied directly to Alan's list. To item 7.18 (Fix boards with different TSC per CPU and kill TSC use on them), he addended, "AND notebooks that vary CPU (and TSC) clock (Toshiba Satellite, IBM ThinkPad) to save power." Christopher Thompson announced in reply:

I have now completed and tested my second TSC patch. It is available at:

This works with 2.3.99-pre8 at least, probably most others. This one disables use of the TSC by an option in the configuration (i.e. make config, make menuconfig, whatever) and therefore has NO performance impact on TSC-enabled kernels. The disadvantage is that this is another option to set in your configuration.

The old patch is available at:

And works for at least 2.3.99-pre6 and pre8, probably most others. This one doesn't use any configuration but rather, determines the situation on bootup. There were some legitimate complaints about this.

I welcome comments and suggestions for improvement. I specifically would like to know how well it works for you and whether it works on a laptop which varies CPU speed (particularly an SMP laptop if such exists).

Just to note: Win2k *does* allow SMP machines with different speed CPUs, despite several people's claims to the contrary.

Martin Mares also replied to Alan's list. To item 1.32 (Fix all remaining PCI code to use new resources and enable_Device), he replied, "Not yet, but thanks to Jeff Garzik many drivers have been already converted." And to item 6.13 (pci_set_master forces a 64 latency on low latency setting devices.Some boards require all cards have latency <= 32), he added that this was fixed in 2.3.99-pre7.

3. Linus Discusses Transmeta Chips

21 May 2000 - 29 May 2000 (16 posts) Archive Link: "8259A initialization with AMD SC520 chip (586)"

People: Linus TorvaldsJamie Lokier

In the course of discussion, Linus Torvalds had some things to say about his work at Transmeta. Speaking of whether Transmeta chips would morph out empty loops, he remarked:

We'd love to, but we don't touch code like that. We could have made the old bogomips give infinite values if we _really_ wanted to, but code like that has one purpose, and one purpose only: delaying. So we never remove those kinds of loops.

(And in any case it would have been extra logic - empty loop removal is very much a special case, so whatever we did would have been an extra wart rather than anything that came really naturally to the way morphing works..)

In a later post, he added:

There's a ton of funky stuff we _could_ do if we wanted to implement the x86 "right". Sadly, we have to be quite careful ;)

[ You _really_ don't want to know about taking page faults in the middle of a task switch that is the result of a task gate being used to handle another page fault, which in turn happened while we were loading the second part of a page-crossing 32-bit word. Question: do you mark the page table entry for the incomplete part that you already checked as accessed or not? ]

Jamie Lokier replied that actually, he did want to know, since he was busy writing an x86 formal spec. Linus expounded:

It actually depends on the CPU, and the type of access.

If it's a "atomic" 32-bit access, you don't mark the PTE accessed, because the page fault will have been noticed before any data was actually fetched. But that is not true for some data that has more "structure" to it that can be loaded as separate pieces and then a page fault part-way through can have already set some of the accessed bits.

The reason it is CPU-dependent seems to be that with speculative loads and out-of-order execution the whole thing becomes much more subtle, and "separate pieces" is no longer the firm thing it used to be. A Pentium core will act differently from a PPro core in many of these special cases.

Nobody sane obviously should ever care. It's hard to even test for, in many cases. We have some rather insane tests, and there's a number of differences between different chips.

Note that many of these things aren't even documented to work. Intel explicitly documents that if you use task switching hardware the TSS should all be on a single page etc. And nobody uses the hardware any more now that even Linux does it all in software. But it's often more painful to be different and have to convince everybody that those differences do not matter than to just try to look exactly like everybody else as far as humanly possible.

4. The Future Of sleep()

22 May 2000 - 25 May 2000 (21 posts) Archive Link: "[PATCH] bttv driver II"

People: David WoodhouseLinus Torvalds

In the course of discussion, David Woodhouse remarked, "How many _valid_ (i.e. non-racing) uses of sleep_on() exist in the kernel at the moment? I suspect it's a miniscule proportion of the occurrences," and Linus Torvalds replied:

We've for the longest time occasionally considered just removing it. Th enotion of "sleep_on()" is a very simple notion, and people understand what it's all about, but most of the uses tend to be buggy.

It might be a good idea to remove sleep() altogether during early 2.5.x. Please remind me. It shouldn't be that painful for most people (but there are probably tons of drivers that need to be updated and tested - 2.5.x is definitely the right point to do this).

5. The LKBS Linux Kernel Benchmark Suite

22 May 2000 - 23 May 2000 (12 posts) Archive Link: "[RFC] Linux Kernel Benchmark Suite"

Topics: Real-Time

People: Guus SliepenAndre HedrickKip MacyLarry McVoyJ. Robert von BehrenVictor YodaikenRik van RielDominik Kubla

Guus Sliepen felt that because of all the recent performance complaints, there really needed to be a standard benchmark suite. He proposed:

I suggest creating LKBS:

I don't know what you think of it, or if there already are such things. If not, I'd happily volunteer to start this project.

Andre Hedrick reached for his megaphone, turned the knob up to 10, depressed the plastic trigger mechanism, and bellowed, "GO FOR IT!!!!!!!!" . He released the trigger, stowed the megaphone, and continued soberly, "Linux needs a standard so that we can do hardware comparisions and provide manufacturers a tool to optimize for Linux. Currently anyone using OTC hardware it is tainted with "WinBench". Specifically DISK caching tables are all tweaked for the other OS.........."

Phil Wilshire suggested joining the Real Time Linux mailing list, by sending "subscribe testing" in the body of a message to ( . He also volunteered to do some work on it himself. Guus replied, "I prefer linux-perf, not only because it's name and the fact that it appears more general than a list at realtimelinux, but also because it has more members, which will give this project more momentum." He added, "I've already set up a (very preliminary) web page at I'll try to make Rik van Riel host it on ( (which is a portal site so many people will visit it, and it has relations with lots of other Linux user groups), unless you or someone else has an even better alternative ofcourse :)."

Victor Yodaiken suggested that 'lmbench' would be the natural starting point for LKBS. Kip Macy agreed with this, and added peripherally, "Out of academic curiousity I ran lmbench on all 60 development kernels. If anyone is interested in the results I will post them to my website." Victor replied with extreme interest, but no URL was posted.

Larry McVoy had some encouragement to offer as well:

I'd really love it if this effort got started. I have a huge backlog of lmbench submissions that I have not processed and put up on the web. I just don't have time these days but the data is there.

Furthermore, I've done a lot of work like what you are proposing and I'd like Linux to benefit from that, but I can't start a project to do that. On the other hand, if there are people who want to work on it, I can certainly help focus the efforts. I've literally spent years doing this sort of thing at SGI & Sun and it seems a waste that I'm not passing on that knowledge/experience. So I'll help if someone else wants to drive.

Guus was very happy about this, and said:

I've just checked out lmbench, that is indeed what I envisioned, except that it does some general benchmarks that apply to most Unices, and I think many developpers like to see their own Linux specific benchmark to go into that too, so they can gather information about the performance of their driver/patch. It was also a little hard to find (I had to use FTPsearch and follow some links), you should put it on Freshmeat IMO :).

This, combined with an automated repository that would gather all information and send digests on request to developpers, would certainly benefit development I think.

J. Robert von Behren was also enthusiastic:

This definitely sounds like an excellent idea to me. I'd be happy to help out, so if you'd like a hand in organizing this, setting up the benchmarks, or creating the site for the benchmark results let me know.

IMO, there are two comparisons that would be really useful in helping to pinpoint performance problems or bugs in the kernel:

  1. tracking how different kernels perform on a stationary hardware platform (ie fixing all hardware variables)
  2. looking at the difference between different hardware platforms for a given kernel

It would also be very nice to link to lists of changes between versions, to help people figure out _why_ performance certain changes in performance occurr.

It might makes sense to move a discussion of this off the kernel list. I'd be happy to set up a discusion list for this - just let me know if people are interested.

Dominik Kubla also felt the topic had left the realm of linux-kernel, and suggested moving to linux-perf, even though that list had been pretty quiet for several months. To subscribe, send "subscribe linux-perf" in the body of an email to ( . Guus replied that he was on that list, and invited others to follow him there.

End Of Thread.

6. Proposal For Kernel Changelogs

23 May 2000 (3 posts) Archive Link: "RFC: kernel changelogs (semi-long)"

People: Jeff GarzikTim Waugh

Jeff Garzik proposed:

When analyzing a kernel code change, it is sometimes not possible to deduce the true meaning of the change from the diff itself. When this happens, analysis of the surrounding code is required, sometimes accompanied by mailing list searches and such.

Occasionally, we even have bad patches which get applied and then un-applied, over the course of six months or a year. From many perspectives -- long term maintenance, short term change evaluation, general code understanding -- a small changelog entry for each change seems advantageous. I think GNOME, egcs, and other projects using changelogs have experience which bears this out.

Since the kernel doesn't have a canonical source code repository[1], we must current on the human (but still brilliant) minds of Linus, Alan, DaveM, sct, tytso, and others. Therefore I propose to have kernel changelogs.

Disadvantages exist too... Gotta get Linus, Alan, and other big contributors to agree. It takes more time, especially for people like Alan who feed lots of changes to Linus. And people will inevitably bicker on changelog entry format.

Three small technical notes:

Overall I believe the advantages outweight the disadvantages. I've always felt that sharing knowledge around has a positive effect, and IMNSHO the Linux kernel community occasionally suffers a bit due to lack of documentation on changes.

Tim Waugh replied, "There already is a drivers/char/ChangeLog by the way, although it hasn't been touched in over a year. ;-)" and Jeff replied, "Unfortunately, kernel changelogs imply Linus enforcement and Alan agreement, otherwise it will fail miserably due to gaps in the docs...." The thread ended there.

7. Virtual Memory: Linux Vs. BSD

24 May 2000 (5 posts) Archive Link: "Linux VM system vs. BSD ditto"

Topics: BSD: FreeBSD, Microkernels: Mach, Virtual Memory

People: Gerard RoudierJuan J. QuintelaRik van Riel

Gustav Kristoffer Ek had been hearing that BSD's virtual memory system was faster than Linux's, when memory got tight. He'd heard that this was because Linux used a "one-hand" algorithm, while BSD used "two-hand", and asked what that was all about.

Rik van Riel confirmed that BSDs VM system was in fact faster than Linux's in those situations, and said that he and others were busily trying to fix that. He added, with a bang of the fist, that neither Linux nor FreeBSD used the one- or two-hand algorithms, and Gerard Roudier expanded:

Linux-2.2 is using the 'one-hand' but 2.3 uses a single LRU. Current fine BSD O/Ses seem to use the active/inactive queue algorithm that may well come from Mach (historians should confirm).

The 'one hand' algorithm made full sense at the time memory size were not that large. IIRC, the 'two hand' algorithm has been invented by BSD guys when memory size increased, for the reason it took too long to do a revolution of the map. This let me think that the 'two-hand' algorithm was rather an hack than a really superior algorithm. Btw, this happened may-be 10-15 years ago, so this may well be just off-topic nowadays. :)

Rik and Juan J. Quintela gave pointers to the 'linux-mm ( ' mailing list archives, but did not point to any particular thread.

8. Linus Releases 2.4-test1 And Goes On Vacation

25 May 2000 (1 post) Archive Link: "[SPOILER] Don't read if you don't like spoilers !"

Topics: POSIX

People: Linus TorvaldsAlan CoxMario Mikocevic

Mario Mikocevic noticed a 2.4 directory in, and a message from Linus Torvalds in, saying:


It doesn't really exist yet.

But I'll be gone for three weeks, and in the meantime there's a "2.4.0-test1" kernel here. It's not a real 2.4.0 release, but we should be getting closer. There's going to be other test-kernels after this one, and we'll find bugs. And bad behaviour. And wonderful features which we'll document some day.

Alan Cox is most likely to maintain a "2.4.0-ac" series while I'm gone. Not the same thing as 2.4.0 either, but by testing these test-kernels out and giving feedback, we'll get to that some day.

Have fun. And let's see how many people find this without it even being announced ;)

(ed. [] I suspect that Linus et al would like to shed a more realistic light on version numbers in general. Proprietary vendors made version numbers such a big deal, because they had to create a product and then stand by it and claim it was the best thing in the Universe. Actually, those best-in-the-universe releases were always largely untested because no one had used them yet! Same with kernel 2.4.0, when it finally comes out. It won't be a finished, final, stable kernel; just one more link on a long chain, a link that means primarily, "now we will try to stabilize the code." The whole idea of accompanying particular releases with lots of fanfare is a holdover, a "legacy feature" once needed for compatibility with other commercial PR teams. But I don't remember seeing it in POSIX.)

9. Alan Releases His First 2.4-test1 ac Patch

26 May 2000 - 29 May 2000 (5 posts) Archive Link: "Linux 2.4.0test1-ac1"

Topics: Disk Arrays: RAID, FS: procfs, I2O, PCI, Sound: Maestro

People: Alan CoxTigran AivazianThomas GraichenTony HoyleJens AxboeMatthew WilcoxAndy HenroidFrancois Romieu

Alan Cox released his first 'ac' patch against the 2.4-test kernel, giving some changelog information:


Base point differences between Alan's tree and Linus

There was not much discussion.







Sharon And Joy

Kernel Traffic is grateful to be developed on a computer donated by Professor Greg Benson and Professor Allan Cruse in the Department of Computer Science at the University of San Francisco. This is the same department that invented FlashMob Computing. Kernel Traffic is hosted by the generous folks at All pages on this site are copyright their original authors, and distributed under the terms of the GNU General Public License version 2.0.