Kernel Traffic
Latest | Archives | People | Topics
Latest | Archives | People | Topics
Latest | Archives | People | Topics
Home | News | RSS Feeds | Mailing Lists | Authors Info | Mirrors | Stalled Traffic

Kernel Traffic #226 For 5 Aug 2003

By Zack Brown

If you like Kernel Traffic and want to send me a little money, click here:

Table Of Contents

Mailing List Stats For This Week

We looked at 1937 posts in 9058K.

There were 536 different contributors. 272 posted more than once. 182 posted last week too.

The top posters of the week were:

1. Continuous Logo Display On Framebuffer

21 Jul 2003 - 24 Jul 2003 (3 posts) Archive Link: "keep the linux logo displayed"

Topics: Framebuffer

People: James Simmons

Ludovic Drolez wanted to keep the Linux logo displayed when using framebuffer on 2.5 or the 2.6 test kernels. James Simmons explained:

That wouldn't be easy to do. In struct vc_data (data about VC tty device) you have vc_top and vc_bottom. Normally vc_top is 0 and vc_bottom is that last row on your screen. For the logo we move vc_top down a little bit. The problem is after we start minigetty on the various /dev/ttyX as soon as you VC switch you reintialize the screen to the standard behavior of vc_top = 0 and vc_bottom is the last row. It would take hacks to the upper console layer to do that.

You can write a userland app to do this. There are esc sequence that change vc_top. You could even alter minigetty if you want.

2. SCO's Claim Of Linux Copyright Violation; Off-Topic Posters Banned

21 Jul 2003 - 26 Jul 2003 (42 posts) Archive Link: "SCO offers UnixWare licenses for Linux"

Topics: BSD, Microsoft, Patents

People: Michael BernsteinDiego Calleja GarciaRichard B. JohnsonLarry McVoyAlan CoxThomas DowningDavid S. MillerFelipe Alfaro SolanaDiego Calleja

Gabor Micsko gave a link to a Linux Weekly News article that in turn linked to a Yahoo news page describing SCO's efforts to get companies to buy a license to use Linux in their commercial operations. Michael Bernstein replied:

Very interesting. It'd be interesting to see if they are able to do this and get past the GPL. However, even if they are selling "Sys V" or "Unixware" licenses, it doesn't mean that they have the right to sell Linux licenses.

To put it simply, just because they "may," - and I say may here simply because we have no evidence to prove their claims but cannot flatly deny them - own the rights to Sys V, does NOT mean they own the right to the code that was released under GPL and does NOT give them the right to reassign a license to it.

If I were a lawyer for the FSF, I'd take this opportunity to investigate how they are selling the licenses, and go smash them up...

Diego Calleja Garcia remarked, "So they want to sell us something that still hasn't proved...." And Richard B. Johnson said:

No. They want to sell you something you already own. SCO is the owner of a non-exclusive license to a 30 year-old operating system. There are many others who have such a license including the University of California in Berkeley. Much of Linux was designed to interface with the API that they published, in a method that minimizes the changes to a 'C' runtime library. This made porting of various Unix utilities developed by the students at Berkeley, relatively easy. The actual Unix API used by Berkeley, was published by AT&T in December 1983. It is Called "Unix System V, Release 2.0, User Reference Manual Including BTL Computer Center Standard and Local Commands". I have a copy of that two volume ring-bound book.

A "non-exclusive license" means that you you are not the only person who has been licensed. It's just that simple. In my opinion there is no way that SCO will ever convince any court that their version of "non-exclusive" is any different than all the others including, but not limited to, BSD, Digital, Interactive, Sun, IBM, Microsoft, Novell, etc. I have read the complaint and they allege that somebody must have stolen their secrets because nobody could make a version of Unix good enough for "the enterprise" without their secrets. So, they contend that they are the only people smart enough to write software for "the enterprise", whatever that is. Nice trick.

Note that in the complaint against IBM, SCO seeks a jury trial. I guess they think it's easier to snow a jury than a judge. We'll see. I think SCO thinks juries are stupid and will treat them as David and Goliath. I think a jury will treat them like thieves, instead.

It is instructive to read the annual reports, filed with the United States Security and Exchange Commission, by many of the companies that produce software. These reports are available on the "Web" and the various company's Web Pages usually have links to recent filings. A quote from a portion of Novel's 2002 Annual report goes like this; " The software industry is characterized by frequent litigation regarding copyright, patent, and other intellectual property rights."

The fact that somebody sues somebody else in the Software Industry is kind of like having the sun rise in the East. You get to expect it. Now, back to writing some software that somebody may claim I stole.............

Close by, Felipe Alfaro Solana remarked that any code actually owned by SCO could be rewritten from scratch, making the whole issue moot. But Larry McVoy put in:

There seems to be a prevailing opinion that if there is stolen code in Linux that came from SCO owned code that all that needs to be done is to remove it and everything is fine. I don't think it works that way. If code was stolen and the fact that it is in Linux helped destroy SCO's business then SCO has the right to try and get damages. I.e., Linux damaged SCO by using the code.

It's also not a simple case of rewriting. _Assuming_ that there was something significant in Linux which came from SCO, i.e., they can make the case that the Linux community wouldn't have thought of it on their own, then you don't get to rewrite it because now you know how whatever "it" is works and you didn't before.

The business world takes their IP seriously. If, and it is a big if, there is code in Linux from SCO, that's going to be a nasty mess to clean up and we had better all pray that IBM just buys them and puts Unix into the public domain. Otherwise I think SCO could force Linux backwards to whereever it was before the tainted code came in. If that happens, I (and I suspect a lot of you) will work to make sure that things which couldn't possibly be tainted (like drivers) do make it forward.

If SCO prevails it won't be the end of the world. A lot of that scalability stuff is just a waste of time, IMO. 32 processor systems are dinosaurs that are going away and I'm not the only one who thinks so, Dell and IDC agree:

Don't get me wrong, there are some cool things in 2.5 that we all want but if SCO puts a dent in the works Linux will recover and maybe be better.

Sancar Saran asked if there were any backup plan, just in case SCO's claims were true; and Alan Cox replied:

Well if IBM did steal stuff my backup plan is to sue IBM, as I suspect is everyone elses. There are basically three outcomes

  1. The whole thing is without merit (as it seems to be now)
  2. IBM did it and have to buy SCO (because everyone will sue IBM, every Linux developer, every business, every user)
  3. SCO gets bankrupted by countersuits (popular US approach to law)

At the moment it seems like the games Intel played against AMD in the 486 days against motherboard vendors, except that Intel had a better case

A couple posts later, Thomas Downing remarked, "I hope someone does take action, SCO vs. IBM doesn't come to trial till April 11, 2005. A lot of damage could be done in that time, assuming some other event (like an acquisition) doesn't obviate the whole mess. To date, the only thing I've seen is:"

At a certain point Larry suggested that the discussion was wandering off-topic; and David S. Miller agreed, and said (as he has said before in the recent past), "People who start off-topic discussions are going to get yanked from vger, and there are no discussions about this."

3. Promise GPLs SATA Driver; GPL Vs. OSL

22 Jul 2003 - 24 Jul 2003 (53 posts) Archive Link: "Promise SATA driver GPL'd"

Topics: Serial ATA

People: Erik AndersenAlan CoxAndre HedrickJeff GarzikSamuel Flory

Erik Andersen announced:

Some folk I've done some consulting work for bought a zillion Promise SATA cards. They were able to convince Promise to release their SATA driver, which was formerly available only as a binary only kernel module, under the terms of the GPL.

So <drum-roll, trumpets> here it is: the Promise SATA driver for the PDC20318, PDC20375, PDC20378, and PDC20618. This driver is released as-is. It is useful for the

Promise SATA150 TX4
Promise SATA150 TX2plus
Promise SATA 378
Promise Ultra 618

cards. As a temporary download location, the GPL'd driver can be obtained from

Have fun! And many thanks to Promise for contributing the driver for their cards!

Milan Roubal was very happy to hear about this, and reported success with the driver on his Promise SATA 150 TX2plus.

Elsewhere, Andre Hedrick was not so happy. After looking over the code, he complained that it was completely obfuscated, and added that he had severed all ties with Promise. Alan Cox replied, "Thats ok - now they are doing GPL drivers themselves they don't need you any more." Andre replied, "don't be surprized when you hard lock the card and the system because the feature does not exist. This is the stuff nobody talks about and the value I added and created, good luck in finding the folks who deploy various asics and are willing to discuss in confidence solutions against the variations."

Elsewhere, Jeff Garzik also replied to Erik's initial post, thanking Promise, and saying, "Bart, Alan, and I have been looking at this. It uses the ancient CAM model, that we don't really want to merge directly in the kernel. It's very close to the libata model, from the user perspective, so life is good." Erik replied, "I was reading over your libata driver yesterday. Certainly a lot cleaner than the cam stuff IMHO. Given the info made available via the Promise driver, I expect that I could get an initial libata host adaptor driver hacked together in short order. After all, the Intel one is just 400 lines. So unless you (or anyone else) have already started or would prefer to do the honors, I'll try to hack something together this evening." Samuel Flory and Mark Watts enthusiastically offered to test anything anyone came up with; and Jeff said it would be great if Erik wanted to write it.

As part of the recent anti-GPL movement, Jeff also added that he'd prefer the code to be entirely written from scratch if possible, so it could be licensed under something other than the GPL, perhaps the OSL. Erik said he'd try, but couldn't guarantee anything, since he might have to take code from the Promise driver.

Various folks started talking about the merits of the OSL over the GPL, and at one point Alan said, "Red Hat is using OSL for various new projects based on the fact that lawyers and legal scholars think that the OSL is the better license to be using and that it achieves desired goals for free software. The kernel however is GPL and its kind of hard to change that. Certainly Red Hat can't do that." He added, "OSL wasn't around when the kernel began or my guess is Linus would have gone that way to avoid political baggage."

4. ReiserFS Speed Enhancements

23 Jul 2003 - 28 Jul 2003 (53 posts) Archive Link: "Reiser4 status: benchmarked vs. V3 (and ext3)"

Topics: FS: ReiserFS, FS: ext3

People: Hans ReiserAndrew Morton

Hans Reiser reported:

Please look at

In brief, V4 is way faster than V3, and the wandering logs are indeed twice as fast as fixed location logs when performing writes in large batches.

We are able to perform all filesystem operations fully atomically, while getting dramatic performance improvements. (Other attempts at introducing transactions into filesystems are said to have failed for performance reasons.)

Balancing at flush time works well, not using blobs works well, allocating at flush time works well. CPU time is good enough to get by, and it will improve over the next few months as we tweak a lot of little details, but the IO performance is what matters, and this performance is quite good enough to use. In all the places where V3 sacrifices performance to save disk space, V4 saves more disk space and gains rather than loses performance.

The plugin infrastructure works well, expect lots of plugins over the next year or two.

Look for a repacker to come out in a few weeks that will make these numbers especially good for filesystems that have 80% of their files unmoving for long periods of time (which is to say most systems), and might otherwise suffer from fragmentation.

These benchmarks mean to me that our performance is now good enough to ship V4 to users (which means we need persons willing to try to crash it so that the stability can become good enough to ship to users). Sometime during the next week or two we will probably send a patch in, and ask for inclusion. We need to run another round of stress tests after our latest tweaks, and kill off two bugs that got added just recently, and then we will ask for testers.

I will be going to Budapest to discuss filesystem semantics with Peter Foldiak for a week, so V4 may get sent in for inclusion by members of my team while I am absent. If so, please include it in 2.5/2.6.

Andrew Morton pointed out that the web site Hans had referenced, "says "but since most users use ext3 with only meta-data journaling" which isn't really correct. ext3's metadata-only journalling mode is writeback mode. Most people in fact use ext3's ordered mode, which provides the same data consistency guarantees on recovery as data journalling. Please compare against the ext3 in -mm. It has tweaks which aren't yet merged, but which will be submitted soon." Hans replied, "We are going to run a bunch more benchmarks when I get back, probably doing things like turning on htrees and tail combining and stuff, in lots of different combinations. Ordered mode will be added, as well as making green have a uniform meaning for all the benchmarks;-). This benchmark was just what could be done before I got on a plane."

5. Status Of IPX Support In 2.6-test

24 Jul 2003 - 26 Jul 2003 (5 posts) Archive Link: "IPX support to kernel 2.6"

People: Alex RiesenArnaldo Carvalho de Melo

Voicu Liviu asked if IPX support would be added to 2.6 so he could mount his Novell disk volumes, and Alex Riesen replied, "It is renamed: ANSI/IEEE 802.2 - aka LLC (IPX, Appletalk, Token Ring) under Networking support/Networking options." Voicu thanked him, but Arnaldo Carvalho de Melo pointed out:

It was not renamed, it just requires that LLC be selected first, then one has to select IPX as before.

I plan to make the LLC1 part, that is all that is needed for IPX, Appletalk and Token Ring to be separated from the big llc module, and making those depending only on LLC1 to be top level in the config, triggering the selection of LLC1 automatically, this will help as well on not having to have LLC2 when all one wants is IPX, Appletalk or Token Ring.

6. udev 0.2 Released

25 Jul 2003 (1 post) Archive Link: "[ANNOUNCE] udev 0.2 release"

Topics: FS: devfs, FS: sysfs, Hot-Plugging, Ottawa Linux Symposium, Version Control

People: Greg KH

Greg KH announced:

I've released the 0.2 version of udev into the wild, after surviving a live demo at the 2003 Ottawa Linux Symposium during a presentation. It can be found at:

udev is a implementation of devfs in userspace using sysfs and /sbin/hotplug. It requires a 2.5/2.6 kernel to run properly. The major changes since the last release is that persistent device naming schemes are now implemented. Yeah, it's pretty rough, but it does prove that the concept is sane and will end up working well for users.

There's a BitKeeper tree of the latest stuff available at: bk://

I've also placed the slides from my OLS talk up at:

The paper which attempts to explain the background of udev, what it does, and where it is going is at:

Due to the rush of the development of udev in this past week (hacking at it during the conference in an attempt to have something to show) there are still a number of very rough corners present, a few known memory leaks, and at least one hard coded path to my home directory for a config file... Please feel free to take it for a spin to see how well things are progressing.

Patches are always welcome, and discussions of the implementation, and future directions that the project should entail are welcome for now on the linux-hotplug-devel mailing list (if it's over-run, a new list will be started up, but I don't think that's necessary for now.)

7. Status Of Software Suspend

26 Jul 2003 (9 posts) Archive Link: "swsusp updates"

Topics: Power Management: ACPI, Software Suspend

People: Pavel MachekPatrick Mochel

Pavel Machek announced, "This updates swsusp: CONFIG_SOFTWARE_SUSPEND and CONFIG_ACPI_SLEEP are separated (it was getting users *badly* confused), remove too noisy printk's, correctly restore console after S3, fixes suspend on machines using yenta_socket.c, fixes some comments, cleans up "interesting" macro mess in suspend.c, no longer eats filesystems when process is ^Z-ed before suspend." Patrick Mochel asked Pavel to split the patches up into single-purpose chunks. Pavel split some chunks off, and submitted them to the Trivial Patch Monkey, and Patrick said:

Why do you insist on abusing the trivial patch monkey? Why can't you send them directly to the maintainers? For instance, you add/remove printk()s and comments that other people may or may not want in there.

But no, this doesn't make me happy because you insist on munging multiple patches together that have little to do with each other, besides the fact they touch the same file. Like I said in private email, it really helps to track down a problem if each patch and subsequent changeset is as small and localized as possible.

And, that's a real problem with swsusp. It's a huge mess right now. I'd like to see it work well and reliably for 2.6, and have the source code be in a state where people can look at it without running away screaming. Convoluted updates are not going to help the situation.

Pavel replied:

If you want to become swsusp maintainer, say so, and you'll be fed nice and split patches *once*. That's okay to do. But I'm not able/do not have enough time to produce split patch each time Linus decides to drop the mail into the bitbucket.

I really don't like "Linus dropped patch -> resubmit 2 patches merged" resulting in you screaming "SPLIT IT UP!" on the lists.

After some private email with Patrick, Pavel then said publically:

patrick seems to have his own "linux-power" tree, and thinks that his "linux-power" tree will help powermanagment in Linux. I don't think that is the case, but I'll provide split patches *once*. Then I'm going to post each new patch (I guess I'll cc: patrick), but cumulate them for submission to Linus. Patches will be marked [PM] (read it as Pavel Machek or Power Managment).

I hope that works for everybody.

8. Status Of UML In 2.6-test

26 Jul 2003 - 29 Jul 2003 (5 posts) Archive Link: "uml-patch-2.6.0-test1"

Topics: User-Mode Linux

People: Jeff Dike

Jeff Dike announced:

This patch updates UML to 2.6.0-test1. There are no functional changes.

The 2.6.0-test1 UML patch is available at

For the other UML mirrors and other downloads, see

Other links of interest:

The UML project home page :
The UML Community site :

Henrik Nordstrom asked how much of UML would be going into the 2.6 tree. He hoped 2.6 would have a good solid UML architecture. Jeff replied, "Linus isn't taking my patches. I'll give him one more try, then see if I can get them in through akpm."

Elsewhere, under the Subject: uml-patch-2.6.0-test2, Jeff announced a new update against 2.6.0-test2.

9. First Ban From linux-kernel: Rick A. Hohensee

28 Jul 2003 (20 posts) Archive Link: "The Well-Factored 386"

Topics: Version Control

People: David S. MillerStephan von KrawczynskiJ.W. SchultzAlan CoxLarry McVoyGene HeskettAlexander ViroTimothy Miller

Rick A. Hohensee posted a long description of the behavior of the 386 microprocessor, and David S. Miller said, "Please stop making off-topic postings. If you continue to do so I will have to yank you from the lists at and filter you from sending emails to the lists." One person replied that Rick's post was not so terribly off-topic, and Rick also replied to David, with an even lengthier post about an assembler he'd written entirely in bash shell. And David banned him, saying:

Rick, I wish you luck finding another machine with lists to infiltrate.

Because you're not going to do it on any more. Bye bye.

Stephan von Krawczynski replied, "Dave, I have to tell you I don't like your attitude shown in this case. Surely you can argue Rick does not really stay on a specific topic, but on the other hand he does not really flood the list, does he? I mean, compared to (name deleted)s' PR bubbles he is really low volume. Besides I have not read any complaints (1 pro) - only yours. Which leads me to think you kill him only because you don't like the man - and not really because of his writing - and because you _can_." David said:

People send me complaints about him every time he posts. And I don't care if you don't like my attitude, my job as list manager is not to be liked by people or to have them like my attitude. My job is to keep the lists clean.

I told people last week that I was going to start cracking down on this. And I was absolutely serious. I know that linux-kernel is often a very unnice place to be subscribed, and I am going to change that.

I publicly asked him NICELY to stop his postings, and he responded with his description of why his x86 assembler written in bash is so great. I have zero sympathy for people who act that way.

Alexander Viro, J.W. Schultz and David D. Hagood all strongly supported David's actions. J. W. added, "Now if we could cut off the threads about BK (as opposed to bk servers) started by anyone other than Larry..." Alan Cox replied, "Even better - by Larry too, excepting when its kernel relevant like downtimes, updates etc." Larry McVoy said to this:

Dave and Linus cc-ed me on the vger crackdown discussions and I offered to unsubscribe from the kernel list if it would help. Dave's comment was that I don't start the wars, which is probably true. I tend to respond to attacks, not go looking for fights. I'd be curious to know when it is that you think I've started a flame fest here, Alan.

I'm here for two reasons, I like OS topics and I want to support BK. That latter one is a problem, the same character traits which make me want to help people when they have problems are the ones that make me participate in the BK flames. If the kernel community is ready to operate on a lower level of support from us, I'll bow out. It hasn't been pleasant being here for the last couple of years and I'd prefer to be gone.

Alan agreed that Larry didn't tend to start flame wars; and J. W., Gene Heskett and Timothy Miller all asked Larry to stay on linux-kernel.

10. Maintainer List

28 Jul 2003 (1 post) Archive Link: "lk maintainers"

People: Denis Vlasenko

Denis Vlasenko posted the latest list of kernel maintainers, saying:

This document is mailed to lkml regularly and will be modified whenever new victim wishes to be listed in it or someone can no longer devote his time to maintainer work.

If you want your entry added/updated/removed, contact me.

BTW, requests to move your entry to the top of the list without actually changing the text are fine too: that will indicate that entry is not outdated, so don't be shy ;-)







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.