Kernel Traffic #285 by Zack Brown

                        Kernel Traffic #285 For 26 Nov 

                                 By Zack Brown

Table Of Contents

  * Standard Format
  * Text Format
  * XML Source
  * Mailing List Stats For This Week
  * Threads Covered

    1. 31 Oct  - 4 Nov  (9       Big Serial Driver Update
                        posts)
    2. 3 Nov  - 10 Nov  (76      Some Discussion Of The Reasons To Support
                        posts)   Older Compilers
    3. 5 Nov  - 10 Nov  (81      Linux 2.6.10-rc1-mm3 Released
                        posts)
    4. 6 Nov  - 10 Nov  (9       PC100 Mouse Fix
                        posts)
    5. 6 Nov  - 10 Nov  (3       Conflicting License Of drivers/char/rocket.c
                        posts)   Resolved
    6. 7 Nov            (7       Linux 2.4.28-rc2 Released
                        posts)
    7. 8 Nov  - 10 Nov  (9       Bitkeeper Diff Enhancement
                        posts)
    8. 9 Nov            (1 post) Real-Time Security Module
    9. 10 Nov           (1 post) Linux PPC Mailing Lists Move To Ozlabs

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:

  * 89 posts in 485K by Greg KH
  * 62 posts in 512K by Adrian Bunk
  * 45 posts in 207K by Andrew Morton
  * 33 posts in 127K by Bill Davidsen
  * 29 posts in 361K by Stelian Pop
  * Full Stats

 

1. Big Serial Driver Update
31 Oct  - 4 Nov  (9 posts) Archive Link: "[PATCH] Serial updates"
Topics: Power Management: ACPI, Version Control
People: Russell King, Andrew Morton, Linus Torvalds

Russell King said:

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

      + unuse register_serial/unregister_serial. Instead, please use
        serial8250_register_port() and serial8250_unregister_port() to talk to
        the 8250 driver.

        The old interfaces have several restrictions:

         1. do not allow the struct device associated with a port to be known
            to the tty layer.
         2. have various restrictions on the size of IO addresses (see the
            HIGH_BITS_OFFSET stuff - which incidentally 8250_pnp got wrong.)

      + provide a mechanism for 8250 platform ports to be dynamically
        registered. We do this via platform devices - either one or multiple
        platform devices. You can have none, one, or as many as you desire.
        8250.c couldn't care.
      + any ports listed in include/asm-*/serial.h will still be intialised in
        preference to platform device based ports for the time being. It is
        intended that everyone will move to using the platform device method.
      + this means that CONFIG_SERIAL_8250_NR_UARTS slightly changes
        definition. It is the number of _extra_ ports above those in include/
        asm-*/serial.h that 8250.h will support. If you have removed all ports
        from include/asm-*/serial.h, then it is obviously the total number of
        ports that 8250.c will support, and you need to make sure that it's
        large enough for your platform.
      + ppc64 broke in this merge. That's expected because I backed out benh's
        changes to the serial drivers. A "get you working again" patch is with
        benh as of last night pending his attention.

    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:

      + ia64 people (ACPI port discovery)
      + parisc people (GSC port discovery)
      + pnp using people

    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  - 10 Nov  (76 posts) Archive Link: "support of older compilers"
People: Matti Aarnio, Chris Wedgwood, Miles Bader, Christoph Hellwig, Adam
Heath, Martin J. Bligh, Ioan Ionita, Linus Torvalds, Xose Vazquez Perez, Chris
Friesen, Giacomo A. Catenazzi, Valdis Kletnieks, Timothy 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:

      + slower
      + generate worse code
      + buggier

    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  - 10 Nov  (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/

      + Added Andi's 4-level-pagetable patches. It's tested on x86, x86_64,
        ia64 and ppc64. These are fairly intrusive patches and I'll probably
        push them upstream soon.
      + UML updates, ppc64 updates.
      + Should fix a few bugs which people reported in 2.6.10-rc1-mm2.

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  - 10 Nov  (9 posts) Archive Link: "[no problem] PC110 broke 2.6.9"
Topics: Assembly, Networking
People: Alan Cox, Linus Torvalds, Andries 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  - 10 Nov  (3 posts) Archive Link: "Licencing of drivers/char/rocket.c ?"
People: Theodore Ts'o, Adrian 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  (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  - 10 Nov  (9 posts) Archive Link: "bk-commits: diff -p?"
Topics: Version Control
People: Geert Uytterhoeven, Larry McVoy, Jens 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  (1 post) Archive Link: "[PATCH] Realtime LSM"
Topics: Real-Time
People: Jack O'Quin, Chris 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  (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."

 

 

 

 

 

 

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