Kernel Traffic #69 For 29 May 2000

By Zack Brown

Table Of Contents


Thanks go to Tom Davey and John Brajkovic for finding some typos in last week's issue. Many thanks, folks!

Daniel Ginsberg disagreed with my stance last week in Issue #68, Section #1  (1 May 2000: CAPP Conformance: The Saga Continues) . He wrote to me:

Dunno about your take on Linda Walsh's posts regarding CAPP conformance. This, in particular, strikes me as unwarranted:

"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."

There really do seem to be two threads to her position. First, that linux will be defacto ruled out as an option by one of its largest possible (and interested) adopters failing certification. But, also, that even given the very real limitations of CAPP, it is a tremendously useful and important part of the security arsenal. Seems to me that on this second point many of LW's detractors have voiced a magic-bullet take on security ("if it won't do all, then why bother"), and she has gone to great lengths to position CAPP correctly in the overall scheme of security, freely granting what CAPP fails to do, but showing the cases in which it would be useful and would contribute significantly to security. Which is to say that I think that she has voiced a pretty honest understanding of the technical merits of CAPP.

Might just be me, but you might want to cruise that thread again.

Daniel, you make a good point. This is the kind of criticism I'd like to see more of from KT readers. It helps expose the real issues underlying the discussion. Thanks for sending it in!

I agree that Linda Walsh is not blindly pushing CAPP just because it's an "official" standard. I didn't mean to give that impression. She obviously cares about the technical aspects, and is not trying to claim that CAPP does everything. On the other hand, I don't think we can say that the folks disagreeing with her are simply looking for some impossible "magic bullet" security solution. Many of them are also qualified, and have legitimate objections. The question of whether it's worth conforming to CAPP is still open.

At the same time, I was trying to draw attention to the fact that at least part of Linda's argument in favor of CAPP is that it's a US government security standard, and would go a long way towards getting Linux accepted in security-conscious environments. Many developers, on the other hand, seem to believe that no matter how much a given feature would help get Linux accepted in a particular environment, that feature should be implemented or not, based solely on its technical merits. These people seem to say that any discussion of CAPP's 'political' value is superfluous, and should be completely ignored.

The quote you took from last week's article, was simply my pointing out that Linda was making such a political case as part of her argument, and that not everyone would like that.

Mailing List Stats For This Week

We looked at 922 posts in 3919K.

There were 368 different contributors. 171 posted more than once. 147 posted last week too.

The top posters of the week were:


1. Early linux-kernel Archives
10 May 2000 - 19 May 2000 (18 posts) Archive Link: "Historical Archive"
Topics: Code Freeze, Spam
People: Alan CoxTheodore Y. Ts'oChris WedgwoodMichal Jaegermann

Alan Cox gave a link ( and announced:

I've had a pile of old stuff from 1993->1995 that escaped due to freak chance and non reuse of an old disk. I've now rescued the data and finally had time to strip the original Linux lists out of it. I dont have 1991/1992 alas but hopefully someone else does. Ted used to have them on tsx-11 I believe /

Anyway if you want to know what DaveM's first post looked like, read the very first Linux code freeze announcement or just wondered what a 5 mail a day kernel list was like..

Theodore Y. Ts'o added:

I have archives from 1991-1994 at:

Any budding historian/archivist want to try to merge the two archives together? :-)

Chris Wedgwood replied:

Since I have my own archives for the last few years (nowhere as extensive as others out there) I have a script to do just such a thing.

I'll snarf down all the archives next week I can get and run it -- it should weed out any duplicates. I might make it a little smarter to record things like origin (which archive source it came from) and also to detect broken messages caused by the horrible unix mailbox format getting truncated in the wrong places.

Something that has occurred to me, some of my archives I deleted the spam from, so they are probably not what you would call 'pristine' condition. I also have a couple of holes 30 messages or so wide form the last couple of years because I've done dumb things like remove and old libc without recompiling my local delivery agent. Doh.

At some point, Michal Jaegermann said:

I found two old CDs which contents is partially Linux. :-)

In particular they contain what seems like a complete archive of linux-activists list starting from November 1991 up to digest 988, Volume #4 from "Wed, 28 Apr 93".

In an off-list email exchange (and many thanks for the quick replies!), Michal also told me:

all this stuff (i.e. everything Linux which was on these two CDs I mentioned) is still available from

But both Andries and Alan have linux-activists archives which go for at least two volumes more than what I found. Some of library sources were missing from Andries collection. :-)

In a later email to me, he added, "the stuff on ( will be not permanently there, a bandwidth to the site is rather limited, it appears that there is not that much in this collection which was not available somewhere else already (some bits and pieces are "new", or rather "sufficiently old" :-) and more complete linux-archivists archives do exist elsewhere."

(ed. [] These old archives are a real find! Up until now, archives of kernel development discussions only went back as far as 1994, when the list maintainer accidentally deleted the existing archive (yikes!). Having a history going all the way back to 1991, the very beginning of Linux, is a treasure of real significance.)


2. SMP On A MIPS Machine
12 May 2000 (3 posts) Archive Link: "SMP MIPS"
Topics: SMP
People: Alan CoxGeorge Anzinger

George Anzinger needed to run Linux on a multiprocessor MIPS machine, but Alan Cox replied discouragingly, "The MIPS tree was never merged for 2.2.x as the changes needed to do all of it never got totally approved/agreed etc."


3. Status Of Asynchronous I/O
13 May 2000 - 19 May 2000 (60 posts) Archive Link: "Can O_SYNC be implemented by using fsync?"
Topics: POSIX, Raw IO
People: Stephen C. TweedieJeff V. MerkeyDan Kegel

In the course of discussion, Stephen C. Tweedie said, "we are working on async raw I/O APIs --- that way you can submit multiple writes at once, allowing the driver to coalesce them and pipeline them, while maintaining all of the cache and synchronisation guarantees of raw I/O." Dan Kegel strummed a happy chord, and asked if the API would be the standard aio_write() function, and Stephen replied, "No, it's far, *far* more powerful than aio_write. The normal posix aio functions like aio_write will be achievable through it, but it will support a lot more (such as things like allowing arbitrary copy of data without it ever having to reach user space at all)." And Jeff V. Merkey sung out, "Bless you Stephen! Let me know when this interface will put rolled into the flat area for 2.4 so I can switch over and start using it. Killer -- a real AIO layer in Linux."


4. Value Of Certification (CAPP Saga Continues)
13 May 2000 - 16 May 2000 (9 posts) Archive Link: "Value of Certifications"
Topics: Networking
People: Linda WalshBernd EckenfelsAlan CoxDavid Woodhouse

Peripheral to the CAPP Debate covered in Issue #65, Section #2  (14 Apr 2000: Proposal: LUID For Secure Auditing) and Issue #68, Section #1  (1 May 2000: CAPP Conformance: The Saga Continues) , Linda Walsh made a case for certifications:

Some people expressed uncertainty about the value of 'paper' certifications that provide no increase in the security of the product in the real world.

I read an article ( that talked about a "smart card" that was the first to be certified to a particular standard (FIPS 140-1). Having the features of the card vs. being certified is worth an estimated $1 billion dollar contract to this company. These Smart Cards could be used, as I understand them, as the "authenticate user" part of the CAPP or LSPP requirements.

I dunno about anyone else...but that's the type of marketshare and money that gets my attention. Having Linux compete in the billion $$ contract space is...well, somewhat "seductive" (not that I'm at all affected by base considerations of such a sum of money, of course, purely from a marketshare POV :-) ). Having that type of money trickle into the Linux space seems like a good thing for all Linux developers (higher demand for services, engineers, Linux software, etc). Tres cool!

Later, she continued:

a product can have the functionality and no cert or the product can meet an insufficiently stringent cert. In either case, the quality of the card may be orthogonal (depends on certification requirements) to the certification. The point here was that the certification itself, not the features, are worth 1 billion. If that was a cert of Linux Based product, for example, say of some particular Red Hat distribution on a VALinux Box with support provided by Linuxcare, and an optional office suite provided by Corel that would mean large amounts of revenues into those companies or those company's Linux operations.

Now other companies may take Linux more seriously and put similar configurations into use in their own infrastructure. Other companies are going to want specific add-ons. The companies who got direct income would likely need more Linux people -> more demand for Linux expertise (Linux Certified Engineers? -- injection of money into LSB?). The point is that a given product (like the smart card company, or Linux companies) meeting a cert send capital into the sector. Even competing smart card vendors are likely to step up their efforts to also get certified -- just as more Linux systems vendors and distro companies would be stepping up efforts to get their respective products on the certified list -> again, more demand for all things Linux. More 'well known' Linux contributors find that demand for their project yields them equipment dumped on their doorstep to bring their product up to release (from beta) quality.

All of this stimulates the Linux 'economy'.

Obviously our goal should be two-fold. A) ensure Linux survival and profitability in the marketplace and B) ensure it is the best there is. Meeting the goals of "A" allow further work on the things we are (I am) interested in long term, which is "B". Doing "A" may not be important for any single one of us, but the fact that it is important enough to pay large some of money for means it is important to someone. Doing "A" *can* allow many of us to work on "B". Hopefully we can finagle many of the "1" goals to contain "2", and for those "2" that don't fall directly into "1"...well who needs nights and weekends anyway? ;-)

When I first got out of school, I was so much the perfectionist / idealist. Now I realize that pragmatism is also useful as it allows expression of my 'art' (yes, I feel for some of us computer science is an 'art' that allows us to express our creativity).

Bernd Eckenfels objected:

Certification will kill the development, once certified this means u have to freze, or get the money for the expensive certifications over and over again... this will force the free software into the commercial hands of companies like SGI.

Don't get me wrong, i personally find it very cool what SGI or IBM is doing for Linux... but I dont want them to gain power on the OS (as SuSE, RedHat or so on).

Alexander S A Kjeldaas and Alan Cox disagreed that certification was necessarily a bad thing. Alan put it, "Certification means SGI and others have to go certify specific versions. THe rest of us will carry on regardless, its their problem. As it stands now Red Hat typically put out 1 or 2 kernels per release so change them very slowly. That doesnt impact Linus's ability to put out 3 a week." And David Woodhouse added, "The certification for ISDN seems to work quite nicely. I don't know exactly what the arrangements are." To which Bernd qualified, "it is only for a hand full of cards, only or selected Revisions of the active cards bios and affects only the isdn subsystem... security cewrtification on the other side affect the whole kernel and a lot of user mode."


5. Development Process
15 May 2000 - 16 May 2000 (2 posts) Archive Link: "aic7xxx 5.1.29 fixes failure on EISA"
Topics: Disks: SCSI
People: Alan CoxDoug Ledford

Gregory Zornetzer asked if Alan Cox would include Doug Ledford's latest aic7xxx driver in the 2.2.16pre series, and gave a link to the patch ( , but Alan replied simply, "Doug's stuff goes in when he asks." That was it.

A similar discussion was covered a couple weeks ago, in Issue #67, Section #1  (27 Apr 2000: Status Of Tekram DC395U Driver; Development Process Explored) , in which a user asked for a particular patch to be included, and Alan explained that it was the maintainer's place to submit it when it was ready.


6. Possible Fix For 'kswapd' CPU Overuse
16 May 2000 - 18 May 2000 (8 posts) Archive Link: "kswapd fixes anywhere?"
Topics: Virtual Memory
People: Rik van RielJuan J. Quintela

Reports of this problem were first covered in Issue #66, Section #3  (22 Apr 2000: 'kswapd' Instability; Debugging Deadlocks) , and showed some improvement in Issue #68, Section #5  (8 May 2000: Virtual Memory Problems Persist In Development Series) .

This week, Matthew Vanecek complained that although plenty of folks were talking about how 'kswapd' was broken, he couldn't find any patches to fix it. He asked if a fix was available, and Rik van Riel replied, "People on the linux-mm mailing list are fixing things as we speak..."

Elsewhere, under the Subject: PATCH: Possible solution to VM problems ( , Juan J. Quintela posted a few iterations of a patch to improve the poor performance of recent development kernels, in particular the problem with 'kswapd' using up 100% of the CPU. Eventually, Rik van Riel replied:

I am now testing the patch on my small test machine and must say that things look just *great*. I can start up a gimp while bonnie is running without having much impact on the speed of either.

Interactive performance is nice and stability seems to be great as well.

I'll test it on my 512MB test machine as well and will have more test results tomorrow. This patch is most likely good enough to include in the kernel this night ;)

(and even if it isn't, it's a hell of a lot better than anything we had before)

End of thread.


7. Problems With Sound On VAIO PCG-F450
17 May 2000 - 22 May 2000 (9 posts) Archive Link: "Sony VAIO"
Topics: Sound: ALSA, Sound: OSS
People: Adam FritzlerJoel Jaeggli

Adam Fritzler bought a VAIO PCG-F450, but (among other things) he asked, "Is anyone working on an OSS driver for the YMF744? ALSA says "mid-May" but thats about it. They have the docs from yamaha on their site as well." Joel Jaeggli replied, "the commercial oss driver (4-front tech) supports it, and they've fixed their "apm calls with the sound driver loaded cause the machine to hang" bug." But Adam didn't want to bother trying to run binary drivers on development kernels. He had no problem running binary user-space software, but binary drivers, no. He said he'd rather write his own Open Source driver instead. Joel replied, "I actually agree with you there. I just tested the oss because I was setting up a laptop (z-505hs)for someone else. the apm bug was really a show stopper in terms of making the laptop useful and of course cements your and my position of binary only drivers"


8. Patch To Use Broken RAM Chips Under Linux
18 May 2000 (3 posts) Archive Link: "BadRAM patch for 2.2.15"
People: Rick van ReinPavel MachekRichard Gooch

Rick van Rein's original BadRAM announcement was covered in Issue #61, Section #17  (24 Mar 2000: Using Broken RAM Chips Under Linux) . This week, he announced version 3.1 of the patch, against kernel 2.2.15, and gave a pointer to it's location ( . He asked for the patch to be included in future 2.2 kernels, but Richard Gooch and Pavel Machek replied that it would probably not get in the 2.2 series, and really belonged in 2.3


9. Synchronizing Patches For The Latest Development Kernels
21 May 2000 (5 posts) Archive Link: "Basic testing shows 2.3.99-pre9-3 bad, pre9-2 good"
Topics: SMP
People: Linus TorvaldsJuan J. QuintelaLawrence Manning

Lawrence Manning reported that 2.3.99pre9-3 had terrible interactive performance, as compared to pre9-2. Linus Torvalds explained:

What happened was really that I did a partial integration just to make it easier to synchronize. I wanted to basically have pre9-2 + quintela's patch, but I had too many emails to go through and too many changes of my own in this area, so I made pre9-3 available so that others could help me synchronize.

So don't despair, pre9-3 is definitely just a temporary mix of patches, and is lacking the balancing that Quintela did.

Juan J. Quintela gave his status, which did not look good:

I am working in introducing my balancing changes in pre9-3, but I am having problems with it. Now my machines get deadlocked and I get a lot of Oopses. I am investigating on that. I get Oops indeed in the pre9-3 vanilla kernel. I am studying it to write a report of the situation.

My SMP machine is new, It has passed 6 hours of memtest86 memory checker, but I don't know what to blame at the moment. I am compiling for my old UP machines to test the differences.

No reply.







We Hope You Enjoy Kernel Traffic

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.