Kernel Traffic #226 For 5�Aug�2003

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.

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

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

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.

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

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!

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.

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.

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

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

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.

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.

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.

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

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.

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.

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.

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 ;-)