Kernel Traffic #285 For 26 Nov 2004

By Zack Brown

Table Of Contents

Mailing List Stats For This Week

We looked at 1935 posts in 12486K.

There were 491 different contributors. 265 posted more than once. 215 posted last week too.

The top posters of the week were:

1. Big Serial Driver Update

31 Oct 2004 - 4 Nov 2004 (9 posts) Archive Link: "[PATCH] Serial updates"

Topics: Power Management: ACPI, Version Control

People: Russell KingAndrew MortonLinus Torvalds

Russell King said:

Ok, here's a major serial update. Items covered in this update:

The patch is about 50K, so won't fit through lkml, and is available here instead:

http://www.arm.linux.org.uk/~rmk/misc/linus-serial.diff

People who should test this patch as a minimum:

Once this lot is in, I'll be following up with a set of patches which removes the serial device tables in include/asm-arm/arch-*/serial.h.

Some folks tested it with good success, while others had trouble applying the patch to Linus Torvalds' current BitKeeper tree. There were a few patches bandied back-and-forth, and at one point Russell asked Andrew Morton, "do you want this set of serial changes to appear in one -mm release before hitting Linus?" Andrew replied, "Not really - there's plenty of time to shake out any problems." And Russell said, "Ok, I'll send a pull request imminently. For those who don't want to wait, latest patch against Linus' tree is at: http://www.arm.linux.org.uk/~rmk/misc/linus-serial.diff"

2. Some Discussion Of The Reasons To Support Older Compilers

3 Nov 2004 - 10 Nov 2004 (76 posts) Archive Link: "support of older compilers"

People: Matti AarnioChris WedgwoodMiles BaderChristoph HellwigAdam HeathMartin J. BlighIoan IonitaLinus TorvaldsXose Vazquez PerezChris FriesenGiacomo A. CatenazziValdis KletnieksTimothy Miller

Timothy Miller asked why so much effort was being put into supporting older GCC compiler versions. He asked, if folks were willing to upgrade their kernel, wouldn't they also be willing to upgrade their compiler? Matti Aarnio pointed out that the latest greatest compilers weren't always the greatest on other architectures. Folks compiling Linux for SPARC and other hardware had to deal with the fact that some compilers worked better than others. As he put it, "We weird people of other architechtures do tend to get "somewhat" conservative over the years in finding, and finally staying with a compiler that we have learned to work. Multiple burned, forever shy..." Giacomo A. Catenazzi suggested that forcing people to use the latest compilers would also expose the bugs in those compilers, so they'd get fixed quicker. Chris Wedgwood countered, "the problem is that I probably want to compile a working kernel *now*, not when the GCC people finally get around to fixing the b0rkedness they added for my architecture in gcc 3.2.3. So I get to keep 3.2.2 around until it's fixed. (Feel free to replace 3.2.3 with whatever arch-dependent value you like)." And Miles Bader added in support of this:

this is particuarly true with fringe architectures.

E.g., you're using a compiler for your CPU that has changes not in mainstream gcc, the vendor who made them is slow in updating to new gcc versions, and their changes are complex enough that you don't want to spend the manpower to port them yourself.

You've got the GPL, so of course it's of course _possible_ to do the work yourself and get a newer gcc working, but sometimes it's really nice to also have the option _not_ to do that...

Elsewhere, Christoph Hellwig boiled the whole problem down to speed. People wanted to use the older compilers, he said, "because the new compilers are a lot slower." This ended up spawning a sizeable subthread. Adam Heath had to clean out his ears before retorting, "You can't be serious that this is a problem." But Martin J. Bligh said, "Yes, it is. Mostly they produce larger, slower code too." And Chris challenged, "try it, say gcc 2.95 vs gcc 4.0 ... i think last i checked the older gcc was over twice as fast" . Adam said he didn't dispute that there was a speed difference; only that it really mattered. He asked, "How often do you compile your kernel?" This turned out to be the wrong thing to say on a kernel developer mailing list. As Chris Friesen pointed out, many folks on the list performed multipler kernel compiles in a day. And Valdis Kletnieks said that a lot of kernel developers used old hardware that could take several hours to compile a kernel from source. Adam insisted several times that the solution was just to purchase better hardware; but this didn't go over so well either. Several folks offered to accept hardware gifts from Adam, or suggested that he send hardware to folks who couldn't afford faster systems.

At one point in that subthread, Ioan Ionita did point out that, "newer versions of gcc, albeit slower at compiling, do tend to generate binaries that have faster execution."

Elsewhere but close by, Linus Torvalds also took issue with Adam's assertion that compile time was not a serious issue. Linus said:

First off, for some people that is literally where _most_ of the CPU cycles go.

Second, it's not just that the compilers are slower. Historically, new gcc versions are:

For a _long_ time, the only reason to upgrade gcc was literally C++ support: basic C support was getting _worse_ with new compilers in pretty much every regard.

Things seem to have improved a bit lately. The gcc-3.x series was basically not worth it for plain C until 3.3 or so.

Adam once more reiterated that people should just get faster hardware if they wanted faster compile times. Linus replied that not everyone could get faster hardware, and that there were other values besides speed when it came to choosing a computer. "Even I tend to prioritize things like "nice and quiet" over absolute speed," he said. But he also said, "Your "use new versions of gcc even if it is slower" argument doesn't make any _sense_. If the new versions aren't any better, why would you want to use them?" Xose Vazquez Perez replied, "Maybe because older gccs are not maintained." Adam also replied to Linus, saying he had no problem with people using older GCC versions if those versions produced more correct code. His argument, he said, was only that speed of compilation alone was not a good enough reason to use an older compiler. He said, "If people don't bother using newer compilers, complaining about their inefficiencies, then the issues will never be resolved." Linus came back at him with:

The only thing that matters is "what is the best tool". And yes, performance _is_ an issue in selecting the best tool. It's not the only one, but it's a major one.

You said so yourself when you claimed people should just buy faster hardware. Again, the machine you use is just another tool. Why should you buy a faster machine if performance doesn't matter?

I don't understand why you first dismiss performance, and then go on to ignore all the _other_ issues I told you about too.

And your argument about "things will get fixed if you use the newer version" is also not actually true. First off, if it ain't broke in the older version, then things _literally_ will get fixed by not upgrading in the first place.

And telling a developer "I'm not using your new version because it sucks compared to the old one" is actually a perfectly valid thing to do, and is likely to be _more_ motivational for the developer to get it fixed than having users that just follow the newest version like stupid sheep.

There are people out there using Linux-2.0. There are probably people even using linux-1.2. And hey, that's OK. For older machines it may really be the right choice, especially if they are still doing the same thing they did several years ago. The notion that you somehow "have to" upgrade to the newest version of software is BOGUS.

3. Linux 2.6.10-rc1-mm3 Released

5 Nov 2004 - 10 Nov 2004 (81 posts) Archive Link: "2.6.10-rc1-mm3"

Topics: Kernel Release Announcement, User-Mode Linux

People: Andrew Morton

Andrew Morton announced Linux 2.6.10-rc1-mm3, saying:

ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.10-rc1/2.6.10-rc1-mm3/

A bunch of folks posted their various oopses, compilation problems, and various other bug reports as usual, which were promptly pounced upon by many developers, and fixes found.

4. PC100 Mouse Fix

6 Nov 2004 - 10 Nov 2004 (9 posts) Archive Link: "[no problem] PC110 broke 2.6.9"

Topics: Assembly, Networking, PCI

People: Alan CoxLinus TorvaldsAndries Brouwer

Andries Brouwer noticed that a recent 2.6.9 bug fix had exposed a deeper problem with the PC110 mouse driver. A test performed by that driver had been broken up until 2.6.9, and so it had just failed to gain access to a region of memory or reserve its IRQ. With the test fixed, the mouse got the IRQ and the RAM, but the Ethernet card got a conflict, so networking wouldn't work. The mouse in turn, with its new RAM and IRQ powers, tried to do I/O but got errors and broke down. So the 2.6.9 bug fix ended up breaking both Andries' networking and mouse operations.

The quick remedy, he said, was to give 'CONFIG_MOUSE_PC110PAD=n' in the kernel config file, disabling the driver entirely; but he thought a better solution would be to detect the conflict at driver load time, and refuse to load the mouse driver if there would be any conflict. He couldn't see a way to detect the hardware, so he'd asked on the linux-kernel list in hopes that someone else knew how.

Linus Torvalds suggested perhaps making this driver link into the kernel late in the game, giving other drivers the chance to claim the resources first and avoid a serious conflict. But he said he had no idea how to probe for the hardware himself. He asked Alan Cox if Alan knew of a way to detect it. But Alan replied, "I have some register info, the driver is done by disassembly of the PC-DOS driver IBM shipped with the PC110. It's a pre pci, pre dmi machine so there aren't any obvious sane ways to probe. Its not something you'd want to build in as opposed to modular on any other system but the PC110." Linus replied:

Well, that actually _is_ something we can probe for: "does this machine have PCI".

IOW, we could have a trivial "if the list of PCI devices is non-empty, then return immediately" kind of thing, no?

That would mean that (pretty much) anybody loading that driver by mistake wouldn't get into trouble.

This sounded good to Alan, and Linus posted a short patch to do it, with a comment in the source code, "We try to avoid enabling the hardware if it's not there, but we don't know how to test. But we do know that the PC110 is not a PCI system. So if we find any PCI devices in the machine, we don't have a PC110.". Andries and Alan both confirmed that this solved the problem on their systems.

5. Conflicting License Of drivers/char/rocket.c Resolved

6 Nov 2004 - 10 Nov 2004 (3 posts) Archive Link: "Licencing of drivers/char/rocket.c ?"

People: Theodore Ts'oAdrian Bunk

Adrian Bunk noticed that the drivers/char/rocket.c file listed two conflicting licenses. The first, at the top of the file, was the GPL. The second one read:

The following source code is subject to Comtrol Corporation's Developer's License Agreement.

This source code is protected by United States copyright law and international copyright treaties.

This source code may only be used to develop software products that will operate with Comtrol brand hardware.

You may not reproduce nor distribute this source code in its original form but must produce a derivative work which includes portions of this source code only.

The portions of this source code which you use in your derivative work must bear Comtrol's copyright notice:

Copyright 1994 Comtrol Corporation.

Adrian felt that the third paragraph of this license conflicted with the GPL (http://www.gnu.org/copyleft/gpl.html) , since it required that the code only be used to develop software for a particular brand of hardware. Adrian asked Theodore Ts'o to clarify the license, and Theodore replied:

I developed the Rocketport device driver under contract of Comtrol, with the understanding that the resulting device driver would be released under the GPL. So I believe the correct way of resolving the conflicting copyright statements is to delete the following lines.

It would be good to get positive confirmation from Comtrol as well that this is their understanding as well. Otherwise, we will need to remove the Rocketport driver from the mainline Linux kernel.

He got this confirmation from Jason Jorgensen of Comtrol, and posted a patch removing Comtrol's copyright notice from the code.

6. Linux 2.4.28-rc2 Released

7 Nov 2004 (7 posts) Archive Link: "Linux 2.4.28-rc2"

Topics: FS: smbfs, Power Management: ACPI, Security

People: Marcelo Tosatti

Marcelo Tosatti announced Linux 2.4.28-rc2, saying:

It contains a network update (which is composed of several smaller changes - IPVS, SCTP, Netfilter), a collection of ACPI bugfixes, a SMBFS client buffer overflow fix (which is very hard to exploit - the attacker needs to control packets from the server), amongst others.

This is going to be become 2.4.28 if nothing bad shows up.

7. Bitkeeper Diff Enhancement

8 Nov 2004 - 10 Nov 2004 (9 posts) Archive Link: "bk-commits: diff -p?"

Topics: Version Control

People: Geert UytterhoevenLarry McVoyJens Axboe

Geert Uytterhoeven requested a BitKeeper feature, asking, "Would it be possible to enable the `-p' option (Show which C function each change is in) of diff for all patches sent to the bk-commits-* mailing lists?" Larry McVoy replied:

This has been fixed in the following releases:

bk-3.2.3
bk-3.2.2c
bk-3.2.2b

Correct usage is "bk diffs -up" which will get you unified + procedural diffs. -p is currently a hack, it implies -u, but don't depend on that behaviour, a future release does this correctly and if you teach your fingers that diffs -p is the same as diffs -up you'll get burned later.

Jens Axboe said, "Thanks! I requested this about a year ago :-)"

8. Real-Time Security Module

9 Nov 2004 (1 post) Archive Link: "[PATCH] Realtime LSM"

Topics: Real-Time

People: Jack O'QuinChris Wright

Jack O'Quin said:

The realtime-lsm Linux Security Module, written by Torben Hohn and Jack O'Quin with significant help from Chris Wright and Jody McIntyre, selectively grants realtime capabilities to specific user groups or applications. One typical use is low latency audio, and the patch has been extensively field tested by Linux audio users.

We developed this LSM in response to a serious need. Audio developers have been struggling for years with having to apply specialized kernel patches to get reliable realtime operation. Audio is very intolerant of scheduling glitches. They cause nasty pops in the output. Also, large audio applications should not run as `root'. The 2.4 "capabilities patch" was never a satisfactory solution for this problem, but it was the best we could do at the time.

Now, thanks to the good work being done on 2.6, we are now close to being able to do serious realtime work with standard kernels available everywhere. The LSM framework is an important element of that solution with the realtime LSM a small but essential component, because it makes these features available without excessive administrative burden. Many musicians have a Mac or Windows background, systems which grant realtime privileges to all tasks indiscriminantly. The realtime LSM allows us to grant similar privileges while maintaining better control over who gets them.

This version was originally applied against linux-2.6.10-rc1-mm2, and retested with linux-2.6.10-rc1-mm4.

9. Linux PPC Mailing Lists Move To Ozlabs

10 Nov 2004 (1 post) Archive Link: "[PATCH] Update ppc list addresses in MAINTAINERS"

Topics: MAINTAINERS File

People: Paul Mackerras

Paul Mackerras announced, "The linuxppc mailing lists that were at lists.linuxppc.org have moved to ozlabs.org. This patch updates the MAINTAINERS file to reflect that."

 

 

 

 

 

 

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