Alan Cox posted his latest To Do list for things to do before 2.4 could come out:

Tony Hoyle suggested adding 2 items to section 7 (To Do But Non Showstopper):

To Tony's first item, Stephen Rothwell posted a patch and explained to Alan, This is realtive to the patch I just sent you and should fix the problems with powering down SMP boxes using APM.

Elsewhere, Steve Dodd asked if item 5.14 (Loopback fs hangs) referred to the "disable plugin" fix that had been discussed earlier. Alan replied that yes it was, and added, Its not merged because nobody has yet explained precisely why it works and if its the right solution. Steve offered a technical explanation, and there was some technical discussion involving him, Jens Axboe, Mike Galbraith, Andrea Arcangel, and Gisle Selensminde. Alan had no more to say.

H. Peter Anvin said it was time to get rid of zImage. He'd pointed it out many times before, but now he really wanted to emphasize that this was the thing to do. He explained:

Given this, he asked, did anyone see a need to support zImage anymore?

There were a lot of replies, and several sizeable subthreads. Brandon S. Allbery pointed out the perennial problem: traditionally, some systems could boot zImage but not bzImage. He asked if this had been solved. H. Peter replied that as far as he knew, all systems could currently boot bzImage. Any exceptions, he said, should be found and fixed. Elsewhere, Edward S. Marshall reported:

H. Peter felt this was probably a BIOS problem, and suggested Edward either use the 'syslinux' boot loader, which would bypass the BIOS block-move feature; or trying a very stripped down bzImage, since he was just interested in whether it would boot, not whether it was ideal (he also misspoke, in this post and others, interchanging "bzImage" with "zImage", making it difficult at times to figure out what was being said. Thanks go to Juan Quintela and Jens Axboe for clearing up the confusing areas). Edward did some tests replied that H. Peter seemed to be right: it looked like 'lilo' was having problems with the BIOS. Using the GRUB bootloader he'd managed to boot bzImage kernels.

Elsewhere, Alan Cox said that getting rid of zImage was really something for 2.5; H. Peter suggested, I would like to suggest making zImage officially deprecated (preferrably including some echo statement in the Makefile), but not removed, in 2.4, and then nuked completely in 2.5. Chris Noe and Johan Kullstam were fine with this, but Tigran Aivazian objected mildly, well, I don't strictly *need* zImage, but, when you are explaining to someone how Linux kernel boots on x86 it is so much easier to follow all the details in the case of zImage than bzImage. But, I agree, it is purely academical thing - I treat all Linux kernels as something one should print out and hang on the wall :)

Andries Brouwer reported that under some old BIOSes, an IDE disk larger than 33.8G would cause the BIOS to hang at boot time. Placing a jumper to make the disk appear the proper size would allow the machine to boot, but access to sector 66055248 and above would give I/O errors. However, he continued:

Werner Almesberger reported that his GA-686LX board with an ancient AWARD BIOS and a Maxtor 93652U8 (~36 GB) was immune to this solution, and that in fact the Maxtor utility wouldn't even recognize the jumper. Andries couldn't believe this, and after a bit of a staircase the thread petered out.

Rui Sousa reported what he took to be an infinite loop in 'kswapd', manifesting as extremely high CPU usage under test1-ac19 on his two-way SMP system. After some discussion, Juan J. Quintela said he thought his latest patch solved several infinite loops in 'kswapd'. He gave a link (after some typo correction) to a patch against ac22-riel. Goswin Brederlow tried this and found it to be less worse, about like the other acXX or plain kernels. Above that in the same email, he'd said, I tried ac22-riel today. its worse than ever, and Rik van Riel replied quietly, God I love detailed bug reports...

Daniel Kobras asked when it was OK to not save/restore processor flags. Specifically, he wanted to know how to determine when spin_lock_irqsave() would be needed in his own code, or if spin_lock_irq() would be sufficient. Russell King explained:

And Manfred Spraul added:

Elsewhere, Matthew Wilcox gave a pointer to The Fucked Up Sparc in the Unreliable Guide To Locking by Paul Rusty Russell.

Some confusion came up over which patches were producing which errors, and in the course of discussion Steven N. Hirsch remarked, I _really_ wish that Larry McVoy's BitKeeper was in regular use, so patchsets can be applied/backed-out in a fine-grained manner. Alan Cox replied, It wouldnt make any odds. Patchsets have complex inter-dependancies. You dont generally want to go playing mix and match. Bitkeeper was first covered by KT in , then again in , and finally made a momentary mention in .

Juan J. Quintela posted a patch, and announced, this patch makes kswapd use less resources. It should solve the kswapd eats xx% of my CPU problems. No one replied with any success, and there was some criticism of the patch.

Russell King reported that during compilation, a lot of files seemed to be getting recompiled even though they hadn't changed. Igmar Palsenberg replied that he'd already posted a bug report on that. He added, The makefile is realy f*cked up since 2.2.16. Try changing 1 c file, do a make and see that make fails after the System.map is created. No errors are shown. Elsewhere, Xuan Baldauf bemoaned the nonexistence of a global Makefile, which he felt would speed up compilation as well as the development process itself. Elsewhere, Mike Frisch also confirmed the problem, and Ricky Beam explained, Well, there is a reason... there is a weak build avoidance system within the kernel makefile system that tries to check the "flags" used during compilation. If something doesn't get its flags marked, then it will be forced to be rebuilt -- I toyed with fixing this, but it's too much of a mess to be fixed easily. You'd think after 10 years, someone would have learned to write a makefile *sigh*

A similar discussion was covered recently in .

Jeff V. Merkey was having trouble building 2.4.0test1 on the IA64. He posted some information, and Jes Sorensen chastized him for posting to linux-kernel instead of the more specific linux-ia64@linuxia64.org list, since as he put it, There is a much bigger chance that the appropriate people will read it there. Jeff objected, I understand that the IA64 folks should get the message in the most efficient manner possible, but unless I am mistaken, there's only "one" master Linux tree, and unless the two are planned to diverge, www.kernel.org should be the central repository for IA64, just like any other Linux port, otherwise, we get the current situation -- the build at www.kernel.org is not always current or at the expected level of completeness that the rest of Linux enjoys. It took me over four hours Sunday to locate and download all the patches and fixes from www.ia64linux.org and hp.com to get the build from www.kernel.org to even compile for IA64. Jes replied, You know what, it's been like that for non x86 ports for years, we try to fold the stable trees into the official tree and keep the architecture specific changes uptodate in the development trees. However things are changing so fast and there is only *one* Linus that you *cannot* in any reasonable way expect to have anything integrated at all times.

In the same post, Jes added, linux-kernel is already so overloaded with rubbish because a lot of people keep posting tons of totally non kernel related questions here (or say answers to the list which are just a personal thank you and a copy of the entire previous email .... hint hint). Having a dedicated mailing list per architecture to handle architecture specific questions is very useful. Jeff replied, I agree so long as folks can get a **WORKING** IA64 linux tree from www.kernel.org. This is clearly not the case today. I am concerned that Intel's IA64 effort may get a black eye if everytime folks download an IA64 Linux from www.kernel.org, they discover that they canot build it. Jes said he could not see Jeff's point. Downloading the sources from www.kernel.org and applying a single patch, produced a working kernel. But Jeff replied that although this might be true, the compilation process produced a lot of warnings and errors, and forced the user to manually edit the config file.

Matthew Wilcox observed, I don't see why ia64 should be treated any differently from mips/arm/m68k/ppc/sparc/... all of which are in the tree and still need separate patches. It's Just The Way It Works. Jeff reiterated that the patches were extremely difficult to apply, but Matthew finished with, the same is true for almost all other architectures.

Jeff was not satisfied, and eventually the thread petered out.

Zlatko Calusic noticed that the 2.4.0-test1-ac21 virtual memory system seemed to remove a test-for-wrong-zone in shrink_mmap(), which caused the system to discard many wrong pages before getting to the right one. In the course of discussion, Linus Torvalds said, The zone test is _definitely_ needed, because without that test we'll deplete zones that have tons of memory and really should not be depleted.. And Rik van Riel remarked, Indeed, and reinserting the zone goodness test makes the system perform wonderfully again. It was removed shortly in -ac21 for unknown reasons. Removing that test was done by a few people on IRC when we tried to identify if that was the cause of high kswapd cpu use on low-memory machines

Rik van Riel and Andrea Arcangeli had another staircase (friendly, this time) about the Virtual Memory subsystem. H. Peter Anvin actually started it off with a report of very bad performance on a high memory machine running 2.4.0-test1-ac22 with Andrea's classzone patch compiled in. Andrea posted a patch, but said he thought the slowdown was not classzone-related. Rik felt that some parts of the patch were wrong, and eventually posted some code of his own. Andrea liked these changes, though he felt it wasn't perfect either, and they went back and forth a bit on the technical details.

Cyrille Chepelov tried comparing 2.4.0-test1-ac22 plus Rik van Riel's strict zone patch, against the same kernel with Andrea Arcangeli's classzone patch instead of Rik's. He measured the cache-, swap-, and buffer-usage of both in a real-world situation. His conclusions were that the classzone patch used slightly less resources. However, it also started applications slower than Rik's patch did, and woke apps out of swap slower as well. Cyrille felt the tests to be inconclusive, favoring neither in any strong way.

Mike Galbraith also did some comparisons between those same kernels, except with Juan J. Quintela's latest patches added in. His measurements involved shoving as much stuff through swap as possible, and he found the classzone kernel to be much faster. There was no discussion.

Florian Weimer asked if a complete list of 2.2 security fixes existed anywhere. He remarked, Alan Cox's "release notes" mention most fixes, but they are remarkably terse regarding security fixes. Is this intentional? Alan Cox replied, They should list all fixes reasonably accurately. They may well not tell you how to exploit them. That is intentional.

An anonymous hotmail account identifying itself only as "Mr. Smith", posted to the list, claiming that various Open-Source-savvy people had told him about an unwritten clause of the GPL and LGPL, in which a distribution of binary-only versions of GPLed code can persist for an unspecified amount of time, as long as the distributor claims that it is only an intermediate package. The anonymous poster sited two cases, involving Tripwire Security and Corel Corporation. In the Tripwire case, Mr. Smith pointed out that, as stated in a press release, they announced they would Open Source their Linux product. But he pointed out that the demo, available at the Tripwire download page, violated the LGPL: Mr. Smith said that even after an inquiry by Richard Stallman, they did not provide object files for relinking to modified versions of the LGPLed library. Apparently Tripwire then claimed that the product was just an "intermediate package", after which they have seemingly been allowed to continue in violation of the LGPL.

In the case of Corel, Mr. Smith claimed that they had distributed CDs of their Linux distribution, without any offer of source code. When questioned, they apparently replied that the software was an "intermediate package". According to Mr. Smith, neither Corel nor Tripwire gave any indication of how long this intermediate phase would last.

There was no truly summarizable discussion, but some interesting tidbits, sometimes peripheral, did surface.

At one point, Jes Sorensen remarked, The real question here is actually why someone hiding behind a hotmail account, without including his real name, posts something like this to linux-kernel where it is completely off topic. And of course the much bigger question why some people just have to reply to it? One can only guess it was a troll.

Elsewhere, Alan Cox remarked, If someone is providing static linked binaries against glibc and not providing the required offer to either provide a dynamic linked one or a .o file (ie an ld -r) of the application and it is on the Red Hat extra applications disk I'd like to know, along with a copy of the correspondance involved.

Elsewhere, Alan also remarked, Actually folks get sued for not following copyrights. I've been talking to someone recently who plans to solve the KDE gpl/nongpl issue by issuing cease and desist orders to KDE. Vendors also take it seriously. Some of them anyway

Richard Stallman also posted to the list in reply to Mr. Smith's initial statement. He said:

Regarding the Corel story, Richard replied, I thought that Corel had abandoned these plans in September. Since then I have heard nothing about it. Would you please give me more details of this activity? What is the name of the product? Can you tell me the names of some FSF-copyrighted programs that are included? And finally, he concluded, no company is entitled to decide to pick and choose which parts of the GPL to follow. We will have to take action, once we get details to base action on.

There was also some talk that the whole topic was not relevant for linux-kernel, and eventually Richard replied to the general sentiment: