Kernel Traffic #226 by Zack Brown
[email protected] Tue, 05 Aug 2003 09:58:04 -0700
| Newsgroups | gmane.linux.kernel.kernel-traffic |
|---|---|
| Message-ID | <E19k58O-0002CR-00@renegade> |
Kernel Traffic #226 For 5 Aug
By Zack Brown
If you like Kernel Traffic and want to send me a little money, click here:
PayPal
Table Of Contents
* Standard Format
* Text Format
* XML Source
* Mailing List Stats For This Week
* Threads Covered
1. 21 Jul - 24 Jul (3 Continuous Logo Display On Framebuffer
posts)
2. 21 Jul - 26 Jul (42 SCO's Claim Of Linux Copyright Violation;
posts) Off-Topic Posters Banned
3. 22 Jul - 24 Jul (53 Promise GPLs SATA Driver; GPL Vs. OSL
posts)
4. 23 Jul - 28 Jul (53 ReiserFS Speed Enhancements
posts)
5. 24 Jul - 26 Jul (5 Status Of IPX Support In 2.6-test
posts)
6. 25 Jul (1 udev 0.2 Released
post)
7. 26 Jul (9 Status Of Software Suspend
posts)
8. 26 Jul - 29 Jul (5 Status Of UML In 2.6-test
posts)
9. 28 Jul (20 First Ban From linux-kernel: Rick A. Hohensee
posts)
10. 28 Jul (1 Maintainer List
post)
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:
* 104 posts in 420K by Alan Cox
* 47 posts in 224K by Geert Uytterhoeven
* 39 posts in 127K by Andrew Morton
* 34 posts in 129K by Tomas Szepe
* 33 posts in 91K by "David S. Miller"
* Full Stats
1. Continuous Logo Display On Framebuffer
21 Jul - 24 Jul (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 - 26 Jul (42 posts) Archive Link: "SCO offers UnixWare licenses for
Linux"
Topics: BSD, Microsoft, Patents
People: Michael Bernstein, Diego Calleja Garcia, Richard B. Johnson, Larry
McVoy, Alan Cox, Thomas Downing, David S. Miller, Felipe Alfaro Solana
Gabor Micsko gave a link to a Linux Weekly News article (http://lwn.net/
Articles/40526/) that in turn linked to a Yahoo news page (http://biz.yahoo.com
/prnews/030721/lam075_1.html) 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:
http://news.com.com/2100-1010_3-1027556.html
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:
www.theregister.co.uk/content/61/31910.html (http://www.theregister.co.uk/
content/61/31910.html) "
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 - 24 Jul (53 posts) Archive Link: "Promise SATA driver GPL'd"
People: Erik Andersen, Alan Cox, Andre Hedrick, Jeff Garzik, Samuel 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 http://www.busybox.net/pdc-ultra-1.00.0.10.tgz
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 (http://www.opensource.org/
licenses/osl.php) . 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 - 28 Jul (53 posts) Archive Link: "Reiser4 status: benchmarked vs. V3
(and ext3)"
Topics: FS: ReiserFS, FS: ext3
People: Hans Reiser, Andrew Morton
Hans Reiser reported:
Please look at http://www.namesys.com/benchmarks/v4marks.html
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 - 26 Jul (5 posts) Archive Link: "IPX support to kernel 2.6"
People: Alex Riesen, Arnaldo 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 (1 post) Archive Link: "[ANNOUNCE] udev 0.2 release"
Topics: FS: devfs, FS: sysfs, 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:
kernel.org/pub/linux/utils/kernel/hotplug/udev-0.2.tar.gz (http://
ftp.kernel.org/pub/linux/utils/kernel/hotplug/udev-0.2.tar.gz)
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://
kernel.bkbits.net/gregkh/udev/
I've also placed the slides from my OLS talk up at: http://www.kroah.com/
linux/talks/ols_2003_udev_talk/
The paper which attempts to explain the background of udev, what it does,
and where it is going is at: http://archive.linuxsymposium.org/ols2003/
Proceedings/All-Reprints/Reprint-Kroah-Hartman-OLS2003.pdf
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 (9 posts) Archive Link: "swsusp updates"
Topics: Power Management: ACPI, Software Suspend
People: Pavel Machek, Patrick 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 - 29 Jul (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 http://jdike.stearns.org/mirror/
uml-patch-2.6.0-test1.bz2
For the other UML mirrors and other downloads, see http://
user-mode-linux.sourceforge.net/dl-sf.html
Other links of interest:
The UML project home page : http://user-mode-linux.sourceforge.net
The UML Community site : http://usermodelinux.org
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 (http://
www.uwsg.indiana.edu/hypermail/linux/kernel/0307.3/1611.html) , Jeff announced
a new update against 2.6.0-test2.
9. First Ban From linux-kernel: Rick A. Hohensee
28 Jul (20 posts) Archive Link: "The Well-Factored 386"
People: David S. Miller, Stephan von Krawczynski, J.W. Schultz, Alan Cox, Larry
McVoy, Alexander Viro, Timothy 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
vger.kernel.org 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 vger.kernel.org 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 tent to start flame wars; and J. W., Gene Heskett
and Timothy Miller all asked Larry to stay on linux-kernel.
The well-factored 386 ( )
10. Maintainer List
28 Jul (1 post) Archive Link: "lk maintainers"
People: Denis Vlasenko
Denis Vlasenko posted the latest list of kernel maintainers (http://
www.uwsg.indiana.edu/hypermail/linux/kernel/0307.3/1138.html) , 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 ;-)
We Hope You Enjoy Kernel Traffic
Kernel Traffic is hosted by the generous folks at Tux.Org. All pages on this
site are copyright their original authors, and distributed under the terms of
the GNU General Public License, version 2.0.