Linus Torvalds reported:

Kai Germaschewski reported success with the patch, but Martin Diehl reported no change in behavior. After some technical back-and-forth with Martin, Linus remarked, Ok, definitely needs some more work. Thanks for testing - I have no hardware where this is needed. After some more discussion, Linus proposed a simple no-finesse solution after getting access to an affected machine. He asked for more comments, but the thread ended with no definite solution.

This thread featured a cute exchange between Linus Torvalds and Alan Cox. At one point Alan mentioned, I've been trying to avoid VM fixes for 2.2.18 to stop stuff getting muddled together and hard to debug. Running with page aging convinces me that 2.2.19 we need to sort some of the vm issues out badly, -- and he added with a smirk -- and make it faster than 2.4test. And Linus replied:

This was the now-famous thread in which Linus Torvalds said:

Jakub Jelinek replied that the bugs reported against Red Hat's gcc had already been fixed, to which Linus replied, That's good. It's even better if you don't play quite as fast-and-lose with your shipping compiler. Jakub also responded to Linus' point about Red Hat's gcc requiring special libraries; he said, Every major g++ release had incompatible libstdc++, even g++ 2.95.2 if bootstrapped under glibc 2.1.x is binary incompatible with g++ 2.95.2 bootstrapped under glibc 2.2.x (libstdc++ uses different soname then; even if we used g++ 2.95.2 we would not have C++ binary compatible with other distributions). Linus replied:

Elsewhere, Alan Cox also replied to Linus' initial post. Responding to Linus' statement that Red Hat's gcc had not been approved by the gcc technical people, Alan asserted that all but two of Red Hat's patches had been accepted into the upstream sources, which he felt showed their approval of Red Hat's choice. He added, The naming did upset people and was unfortunate, but done talking to the compiler folks at Red Hat with the best of intentions behind it. If we had called it 'Red Hat cc' I think people would have been even more offended at the way they had been discredited. To Linus' point that Red Hat's gcc was so broken it required special libraries, Alan said, Wrong - the C++ vtable format change is part of the intended progression of the compiler and needed to meet standards compliance. gcc 295 also changed the internal formats. Unfortunately the gcc295 and 296 formats are both probably not the final format. The compiler folks are not willing to guarantee anything untill gcc 3.0, which may actually be out by the time 2.4 is stable. Linus replied:

Alan pointed out that gcc 2.95 had a different format, gcc 2.96 had a different format, and egcs 1.1.2 had a different format. So, he said, they all had different formats from all others, except that gcc 2.96 was also a c++ compiler. Bernhard Rosenkraenzer also replied to Linus, saying on similar lines as Alan, The same thing is true of *any* gcc release. For example, C++-ABI wise, 2.95.x is incompatible BOTH with egcs 1.1.x _and_ the upcoming 3.0 release. But Miquel van Smoorenburg put in:

Alan accused:

Miquel replied that he'd been half-joking and should have included a smiley. But Michael Peddemors asked, regarding Alan's second item, Curious HOW do you tell vendors?? To which Alan replied, When they ask. He went on, More usefully Dan Quinlann and most vendors put together a recommended set of things to build with and use. It warns about library pitfalls, kernel changes and what packaging is supported. It is far from perfect and nothing like the LSB goals but its a start and following it does give you applications that with a bit of care run on everything. At this point Theodore Y. Ts'o came in with:

He added, Ever since Jim Kingdon left Red Hat (he was at VA Linux for a while, and is now at SGI), as far as I know no one at Red Hat is actively participating in the LSB activities --- they haven't sent anyone to the physical LSB meetings, or participated in the bi-weekly phone conferences, or taken work items to help finish the LSB. Alan does participate on the mailing lists, and makes quite helpful comments, but as far as I know that's about the limit to Red Hat's participation to either the LSB or the LDPS specification work. Speaking as someone who has been contributing time and effort to the LSB, it would be great if Red Hat were to become more fully involved in the LSB; I (and I'm sure all the other LSB volunteers) would welcome a greater level of participation by Red Hat.

There was no reply.

Another threadlet branched out of Alan's initial reply to Linus' first post. To Linus' hope that Red Hat downgrade their gcc as soon as possible, Alan said:

Linus replied:

[...]

Alan pointed out that 2.96 was actively maintained -- by CygnusHat -- and that they fed all changes back to the core gcc team. As for marking snapshots as snapshots, Alan said, That it was confusing and mistaken by some as an official GNU group release is something we never intended and have already apologised for. It was done without malice or ill intent. And to Linus' recommendation that developers use Red Hat 6.2 in preference to 7.0, Alan agreed, saying, We strongly recommend that people use 6.2 for developing binaries for general release unless they have specific requirements for glibc 2.2. Thats the same guidelines the LSB 'oops we havent finished yet here is a quickie for now' documentation recommends.

Bernhard also replied to Linus' suggestion of 2.95.2 as being actively maintained. Bernhard asserted that it wasn't as actively maintained as it could be, and added that a comparison of numbers of patches in the 2.95 tree against the 2.96 tree in Red Hat's Rawhide distribution would show more activity on 2.96. He added that he didn't think the current 2.96 code was any more buggy than the current 2.95 code. He also went on to say that Linus' suggestion of egcs may be good for the kernel, but it's not acceptable for C++. Regarding Bernhard's comparison of 2.95 upstream to 2.96 in Rawhide, Linus replied:

For anyone interested, there was some mention of 2.96 instability in . 2.96 was still not recommended by (though Alan felt the problem was more with the kernel than the compiler). Horst von Brand agreed with this assessment in , though Red Hat was already taking flak for releasing their gcc snapshot under the false name 2.96; and Peter Samuelson felt that 2.96 would break any known kernel, in .

Someone noticed that the kapm-idled process nromally took up between 60% and 80% of the CPU, but only when no other processes were running. Rik van Riel replied, What do you suppose the 'idled' in 'kapm-idled' stands for? Nick Holloway replied, We know it was an attempt to stop people complaining about the fact that "kapm" was hogging the CPU. Looks like it doesn't work. The original poster also replied to Rik, saying that the behavior was misleading, and seemed to show a constantly loaded CPU. And Kurt Garloff put in, Even worse: Formerly you could take conclusions from the sys part of your load. This is not possible any more. I dislike this as well and consider it a cosmetical bug. (Which is much better than a real bug, don't get me wrong. If fixing the cosmetical one introduces a real one: Don't do it!) There was some discussion of possible improvements to the situation, but nothing conclusive emerged from the list. For an earlier discussion on this issue, see .

Rico Tudor asked, Does anyone have reference material for the ServerWorks northbridge? I want to add their chipsets to my ECC-monitoring utility, but their web site is little more than marketing drivel. Plus, they don't respond to e-mail. J.A. Magallon gave a link to some ServerWorks drivers. But Dave Jones felt that this page only indicated that chances of them publically releasing register level info seems pretty slim. He added that he'd tried several times to get docs out of them and failed. Dan Hollis remarked, serverworks requires you not only to sign an NDA, but also do all development on-site at their santa clara HQ under their direct supervision. But Jeff Nguyen said, Serverworks wants to support the Linux community. Thus they are willing to share certain information to developers without risking the IP. Recently ASL has been working with Serverworks in supporting the lm-sensor project and other Linux software developer. Let me know if you need some help with the chipset information. Rico replied that without the docs, the basic problem remained. He went on:

Matthew Jacob had a few factual points to make against Rico's post. First, he pointed out, The only source for the OS that came 'for free' that I can recall for the PDP-11 was RSX-11- but that was only the bare kernel. The filesystem and the utilities's source wwas not available. At that time, as you can probably well recall, the UNIX source licence from WECO was 40K$ for v7 at Sidereal. Regarding kudos for IBM and Intel, he went on, Don't applaud either Intel or IBM too loudly. In particular, Intel. Just *try* and get documentation about their frickin' gigabit ethernet chip out of them.

Jeff also replied to Rico, quoting an email from Jim Forster of Serverworks, in which Jim said, We want to enable the Linux community as quickly as possible; we agree with you that it makes business sense to do so. Given the fact that our IP is our sole product, we cannot release our technical documents to the world at large. We have been working to create an extract of our documents to enable the Linux community. As a small company experiencing tremendous growth, our support infrastructure must focus on our existing customers. At this time, I do not have an estimated release date for the technical extract. ... We are continuing our work to enable the Linux community. Can you think of any alternative methods to enable the Linux community without exposing ourselves? I'm certainly open to new ideas...

Jeff explained:

There was no reply.

Rasmus Andersen posted a short patch to remove the 'static' declaration of the cfi_probe struct, which caused it not to be shared. Taking this out allowed the kernel to successfully pass the linking process, though Rasmus admitted he wasn't sure if the behavior he'd changed had actually been intended or not. Keith Owens replied that between test11 and test12, someone had added code to do conditional compilation; which, Keith said, added needless complexity and was therefore wrong. He asserted that this earlier change should be undone and the cfi_probe returned to a static declaration. However, David Woodhouse defended the change, pointing out that the conditional complexity was necessary to accomodate variations in linking order. To this, Keith replied, Messing about with conditional compilation because the link order is incorrect is the wrong fix. The mtd/Makefile must link the objects in the correct order. He listed what he felt to be the proper link order of various .o files, and suggested a link-order change for mtd.h; but David still disagreed with that solution. He said:

Keith asked, The rest of the kernel already depends totally on these "subtle" issues with link order. Why should mtd be different? Alan Cox chimed, Why should mtd be broken just because the rest of the Makefiles are? David also replied to Keith's question, saying, Because I maintain the MTD code and I want it to be. I think the link order dependencies are ugly, unnecessary and far more likely to be problematic then the alternatives. I'll code an alternative which is cleaner than the current code, and Linus can either accept it or not, as he sees fit. Keith pointed out, Your choice. Just bear in mind that if CONFIG_MODULES=y but mtd objects are built into the kernel then mtd _must_ have a correct link order. Consider a config with CONFIG_MODULES=y but every mtd option is set to 'y', link order is critical. The moment you have two or more mtd modules built in then you are stuck with link order issues, no matter what you do. Of course you could invent and maintain your own unique method for controlling mtd initialisation order ... David admitted he had no answer to this problem, and mentioned, The patch was actually put in by someone to fix 2.0 compilation - and I noticed that it made the link order problem go away for certain configs. He went on, I'll try to find a clean way to make the MTD code work in all configurations without having to do that. If it really comes to doing the above, I'll probably just give up and let it stay 'broken' (IMO) along with the rest of the kernel code which as you say already has link order dependencies. End Of Thread (tm).

In the course of discussion, Brady Montz asked if anyone knew some docs explaining the benefits of NFSv3. Alan Cox replied, Not off hand but I can give you a very brief summary of the big one - write speed. NFSv2 does synchronous writes with a minimal amount of write ahead. NFSv3 gathers writes on the server and schedules them as the server wishes. The client sends write requests but before it can assume them completed and thus clear that part of its cache has to commit them. Normally the commit is done well after the I/O hit server disks, if not it waits and Andrea Arcangeli added, another relevant feature is that with 2.4.x and 2.2.18aa2 you also get >2G files with NFSv3 (like on top of ext2).

Abraham vd Merwe had Linux running on his camera, using the binary-only M-Systems DiskOnChip driver for storage and as a boot device. But he reported, The problem is if we boot with a kernel WITH vga support enabled, it boots fine. If we disable vga support it doesn't seem to boot. What makes it even stranger is that if we boot with that same non-vga kernel using an IDE disk as boot device it also boots fine. Alan Cox replied, Please ask M-Systems to debug your problem. We don't have source code to their driver so we cannot help you.

Richard B. Johnson noticed what looked like a performance problem in the Virtual Memory subsystem of kernels 2.2.17, 2.4.0-test9, and 2.4.0-test12. He'd written a test program to allocate (via malloc()), use, and then free some RAM. He noticed that all memory would be freed quickly and efficiently if he CTRL-C'ed out of the program, while if the program were allowed to reach its own deallocation code, it will take even up to 1 whole minute!! At this time, there is an enormous amount of swap-file activity going on. He argued, Since many programs allocate/deallocate data by setting the break address via malloc(), this represents a severe performance penalty. Deallocating pages should not result in any swap-file activity! This activity should occur only when whatever got swapped out, needs to get swapped back in and nothing needs to get swapped back in during a deallocation! Since user's pages are not reordered (or should not be), there should be no swap activity during page deallocation. David S. Miller asked, How exactly are these buffers allocated/deallocated? Are you absolutely certain that the deallocation process does not make loads from or stores into the buffers as a free(3) implementation would? That would cause the pages to be sucked back from swap space. Richard replied that he just used free(), as any typical user program might. But David replied, malloc and free maintain their free buffers pools using linked lists, thus a free() does two stores to the (2 * sizeof(void *)) bytes before or after that buffer. Thus the swapping. Use mmap()/munmap() directly and manage things totally yourself to get rid of this.

Alan Cox recently started maintaining his own set of patches against the 2.4-test tree, feeding some to Linus Torvalds for official developer releases. He announced 2.4.0test13pre3-ac1 and said, This is mostly so people can see what I have merged in my tree and what has gone from it. The patch for the adventurous is in ftp://ftp.kernel.org/pub/linux/kernel/people/alan/2.4.0test/ and posted the Changelog:

Alexander Viro pointed out that for item 2 (Fix leak in link() syscall), the fix had originally come not from him but from Christopher Yeoh. There was very little other discussion, but Tim Waugh posted some patches.

Andre Hedrick announced:

David Weinehall replied, Well, I think that most people can be happy with the conditions. Now, the format, that's a completely different issue. With all your influence, I bet you could persuade them to at least run the document through Acrobat Distiller to turn it into a .pdf?! Andre replied, My bad for forwarding info from internal. I knew that my copies were in PDF, but did not know if they combined all the erratas in to a newer doc or what....

John Reiser announced, Beta release v1.11 of the UPX executable compressor http://upx.tsx.org offers new, tighter re-compression of compressed Linux kernels for x86. Additional space savings of about 15% have been seen using "upx --best vmlinuz" (example: 617431 ==> 525099, saving 92332 bytes). Both source (GPLv2) and pre-compiled binary for x86 are available. Adrian Bunk pointed out that the project was not fully GPLed, but had a special exception for a portion of the binaries. He gave a link to the text of the license, but Frank v Waveren and John argued that this was merely a case of dual licensing, not of additional restrictions; and John explained, The UPX team owns all copyright in all of UPX and in each part of UPX. Therefore, the UPX team may choose which license(s), and has chosen two. One of them is GPLv2. The UPX team understands, and fully intends to abide by, its obligations under GPLv2 when any software that is subject to GPLv2 is contributed to UPX and re-distributed by the UPX team. The other license is detailed in the LICENSE file, but may be summarized as: free to use if unmodified, and if used only to invoke the program, and sublicensable only under the same terms. This permits using UPX to pack a non-GPL executable. Users of UPX (as distributed by the UPX team) may choose whether to use UPX according to GPLv2, or according to the other license.

Someone gave a pointer to an article in theregister, discussing hardware-based copy protection. He said the technology seemed easy to defeat, but Alan Cox replied, Its probably very hard to defeat. It also in its current form means you can throw disk defragmenting tools out. Dead, gone. Welcome to the United Police State Of America. He also added, I'm just waiting for a few class action law suits against drive manufacturers when people's backup tools cannot cope. To this last, Andre Hedrick replied:

End of thread.