Linda Walsh posted a patch to implement some initial elements of the code necessary for CAPP security compliance. See for the first coverage of this debate.

This week the discussion continued in much the same tone. Linda (speaking for SGI) argued that CAPP conformance was necessary for systems needing high security; but other folks raised many objections. Some reminded her that the kernel was in feature freeze, so this sort of thing should wait until 2.5; but Linda countered that it was important to get as much of the code into 2.4 as possible, so specialized CAPP patches could be smaller and more palatable to security-minded organizations. Another objection was that CAPP was a broken standard, and should be ignored. But Linda argued that it was "government issue", and had a lot of influence even if it wasn't perfect. This part of the debate is probably key to the eventual acceptance of the code into the kernel, but Linda does not seem to be convincing people of CAPP's integrity, try as she might. I suspect that she puts more weight on its status as an "official" standard than other folks on the list, who are concerned primarily with its technical merits.

This led into another objection, which was that folks felt they were being asked to accept patches into the main kernel without really knowing what they were for or where they were really headed. As Alexander S. Guy put it at one point in the discussion, I couldn't give a rat's ass about claiming certification. I want an architected security solution that is comprehensive, and actually functions. In response to this, Linda gave a lot of technical details of her proposed implementation, adding, We have been letting folks know -- we are active in other security project lists, my manager has been on the speaking tour and mentioned more than once on slashdot -- the whole giving away the B1 on OSS has been mentioned more than once. I spoke in Florida last week and have 2 European speaking engagements in June, another one in August, and another unconfirmed possibility in July. Most of these talks (SGI "Linux" University) are open to the public, the others are at public conferences. Meanwhile we are trying to move while the movin' is good. :-) She went on, For the user level programs we are looking at distro industry partnering. We've already partnered w/RH in an earlier release to add in some I/O enhancements or something (I'm not sure of the exact details, 6.0 I think) for Oracle. We are partnering in the Trillian project for ia64 Linux and want to see Linux be a fully commercial player -- hopefully scaling up to the number of processors IRIX supports (currently 256P). My and my group's work on 'trusted' Linux is just another aspect of our desire to contribute and enhance Linux.

As in the previous discussion, Linda stood almost entirely alone throughout the thread, although it's clear that she's highly qualified. It'll be interesting to see how the debate progresses through 2.4 and 2.5

Roman V. Shaposhnick posted a patch that Linus Torvalds did not think much of. In fact, Linus flamed it and the mailing list that discussed it. Brian J. Murrell could not believe his eyes and analyzed the post to see if Linus' address had been forged. He exclaimed, I would hate to think Linus would "rip anyone a new one" in this fashion. It certainly does not ring too well to the tune of "The Cathedral and the Bazaar"'s discussion on cultivating OpenSource programmers. Alexander Viro replied, Nah, not a forgery. WTF, who decided that Linus is not allowed to flame? If you want to start linux-kernel-nicey-nicey - feel free to do so. David Parsons added, Linus, thank goodness, does not hire style consultants to teach him how to follow the political fashions of the day. Linus quite cheerfully rips people new ones whenever a proposed patch is submitted that he cares enough to comment on its shortcomings. And Nathan Hand put in, A leader with neither bark nor bite isn't worth following. Linus also explained:

Roman accepted the apology, and there followed a bit of technical discussion in which Linus seriously considered the merits of Roman's patch.

Ron Van Dam felt that the reason new stable series' were always "delayed" was because of feature-creep during the later stages of development series'. He suggested having two separate development trees running concurrently. In the current case, it would be 2.5 and 2.7; in which 2.5 would have specific, predefined goals not to be exceeded, while 2.7 would get all the fall-through features that hadn't been determined beforehand. That way 2.6 could be completed in a predictable amount of time. The discussion quickly veered off into other areas, but Marco Colombo gave links to a prior discussion, having the Subject: "Standard Development Integration", continuing here, and here.

In the course of discussion, Ian Carr-de Avelon observed, I think part of the general problem with the speaker driver is that progresively smaller cheaper speakers have been put in by the makers, so generally only older PCs give something approaching AM sound. Vladimir Dergachev replied, Most computers that I saw have a small nice speaker (the sort you could see in radios couple decades ago). The problem however is not with speaker but with the way it is driven (on and off if I remember correctly). That is the speaker can either be told to emit a square wave at a certain frequency (which is used for beeps) or you can drive that square wave with cpu. Hence unlike sound cards that have from 256 to 65536 gradations (or more) pc speaker has 2. David L. Nicol asked if it were possible to control the tone by driving the speaker for very short periods of time, and Richard B. Johnson replied:

Zlatko Calusic finally had enough of bad virtual memory behavior in recent development kernels, and cited some history:

He posted a patch, and explained, this patch mostly *removes* cruft recently added, and returns to the known state of operation. After that is achieved it is then easy to selectively add good things I might have removed, and change behaviour as wanted, but I would like to urge people to test things thoroughly before releasing patches this close to 2.4. Rik van Riel pointed out that his patch was broken for high memory machines, and remarked, Think of a 1GB machine which has a 16MB DMA zone, a 950MB normal zone and a very small HIGHMEM zone. With the old VM code the HIGHMEM zone would be swapping like mad while the other two zones are idle. Zlatko replied that now he understood what the VM code was aiming for, but complained, still, optimizing for 1GB, while at the same time completely killing performances even *usability* for the 99% of users doesn't look like a good solution, does it? Linus Torvalds replied:

The discussion continued, and at one point Paul Barton-Davis remarked:

A bit elsewhere, Linus suggested, Try out the really recent one - pre7-8. So far it hassome good reviews, and I've tested it both on a 20MB machine and a 512MB one.. But Simon Kirby, Niels Kristian Bech Jensen, Florin Andrei, Christoph Rohland and James H. Cloos Jr. all reported little or no improvement. Linus felt there might be some bad interaction with some other code, but he couldn't pinpoint it.

Later, Linus announced pre7-9, but folks reported no improvement whatsoever. At one point Linus commented, I think Ingo already posted a very valid concern about high-memory machines, and there are other issues we should look at. I just want to be in a position where we can look at the code and say "we do X because Y", rather than a collection of random tweaks that just happens to work. The discussion went on for awhile, as Linus and others got down and dirty with the code, but no clear solution emerged.

However, under the Subject: VM performance..., Mikael Grahn reported, I just thought i would give my word on the VM performance problems. There has been alot of talk around this problem the last week. New pre patches come and it doesn't seem to help. Linus said that the new pre7 patch would make it better. I applied it and not surprised i noticed no change. There is however some light in the darkness. The nice classzone patch by Andrea Arcangeli is very nice ! It has killed all the performance problems over here. Now i can at last do heave I/O work and still use the computer at the same time :) Great work Andrea ! Luca Montecchiani confirmed this experience, as did Florin. Florin added, though, that VMWare would die with the classzone patch. He and others acknowledged that this wasn't really the kernel's concern, and Yoann Vandoorselaere put it, I think vmware contain many hack and is very dependant on the kernel, which make it very sensible to whatever kernel change. If the application is in cause, it need to be fixed... not the kernel ( so if including the classzone patch is good for the kernel VM gestion ( what i think ), we should include it, right ?) . The thread ended there.

Matthew Kirkwood ws getting a lot of stalls from the eepro100 driver under 2.2.15pre7 with Red Hat 6.2; Alan Cox recommended the driver from 2.2.14, and to report to Andrey Savochin regardless of the result. Anthony J. Biacco confirmed Matthew's report, adding that he'd had problems with the driver on all stable kernels up to 2.2.14, but he went on to say that 2.2.15pre18 seemed to fix it. Elsewhere, Tim Hockin reported:

Matthew replied that his machine was on a Cisco Catalyst switch, but that the problems he observed were different from what Tim had described. Matthew would regularly see stalls half-way through downloading web pages. Nothing came of this, but Andrew Morton also replied to Tim, saying:

There was a small amount of technical discussion, and Henning P. Schmiedehausen threw into the soup:

No clarity came through the list.

A one-day bug hunt. Tigran Aivazian reported that running 'fuser' under 2.3.99pre7 or pre8, would cause the mount count of '/proc' to grow by 1 at each 'fuser' invocation. Alexander Viro said he'd look into it, then 3 and a half hours later puzzled, How quaint... chdir("/proc/self/fd"); gets the process into the state where it will correctly deal with further chdir() calls, but fail to release fs_struct (contents?) upon the exit. It looks like a change of some state: been there once and that's it - you are doomed. WTF??? More coffee needed - it's getting seriously weird... Tigran replied privately, saying he would look into it as well, now that Alexander had narrowed it down. They went back and forth a bit, and Alexander posted some patches. At one point, Tigran said, once we chdir("/proc/self/fs") (or any directory name containing that e.g. "/proc/self/fd/../..") our fs->count gets incremented one extra time so not only we leak /proc's mnt_count but also root's, i.e. the whole chunk of code in __put_fs_struct() is never executed. So, the question is - why/where do we increment fs->count the extra time? And to one of Alexander's patches, he replied, yes, that fixed all of it, i.e. both root and pwd not have correct mnt_count and /proc umounts just fine..

Deven T. Corzine had a long proposal for regularizing kernel version numbers so people could get an idea of where the development process was at any given time. To do this, he proposed adding an additional number to the version numbers of the development series. He summarized the current method, in which x.even.y represented kernels aiming for stability, while x.odd.y represented kernels adding new features and revamping bad ideas. To illustrate his idea, he took the next series as an example:

Someone pointed out that this didn't really reflect the way the kernel was actually developed. He pointed out that generally the unstable series tended to add a bunch of patches and become really unstable, then stablize for a bit, then add more patches, then stablize some more, and so on. Daven replied that his new scheme would at least help keep people informed as to where the kernel was supposed to be. Michael Poole described his own observations of actual development:

There was not much support for Daven's idea, and the thread petered out.

Ling Su had a PCI device driver that required response times of approximately 50 microseconds. He asked if Linux could handle this on something like an 800 Mhz Pentium III, or if he should look into RTLinux. Victor Yodaiken recommended RTLinux, but added, Linux is actually amazingly good normally, so if you need "typical" response within 50us then you could probably do without RTLinux. But if you need, "worst case" to be less than 50us it's not a problem unless you need to do a 40us processing every 50us. Peter Monta agreed that if you can tolerate occasional few-millisecond delays, the plain kernel may suffice, otherwise RTLinux was the way to go, he said. Later, Alan Cox also put in, We don't try to be 'seriously realtime' in paticular we don't deal with priority inversion and kernel pre-emption. If it hurts when you miss deadlines look at RtLinux.