Kernel Traffic #246 by Zack Brown

                        Kernel Traffic #246 For 26 Dec 

                                 By Zack Brown

Table Of Contents

  * Standard Format
  * Text Format
  * XML Source
  * Introduction
  * Threads Covered

    1.  3 Dec  - 18 Dec   (276    Discussion Of Binary Modules; Linus Prefers
                          posts)  OSL License To GPL
    2.  8 Dec  - 14 Dec   (107    Status Of DevFS/udev In 2.6
                          posts)
    3.  10 Dec  - 12 Dec  (11     Linux 2.4.24-pre1 Released; XFS Merged
                          posts)
    4.  11 Dec  - 12 Dec  (7      New -tiny Kernel Patchset To Collect Patches
                          posts)  That Shrink The Kernel
    5.  11 Dec  - 15 Dec  (14     Revised 'Unreliable' Kernel Locking Guide
                          posts)
    6.  14 Dec  - 21 Dec  (33     Larry Pulls Another Larry
                          posts)
    7.  14 Dec            (2      Status Of CONFIG_USB_DC2XX In 2.6
                          posts)
    8.  15 Dec  - 18 Dec  (4      Update Of Experimental Net Driver
                          posts)
    9.  17 Dec  - 19 Dec  (17     Status Of -mm Tree And 2.6
                          posts)
    10. 17 Dec  - 18 Dec  (47     Linux 2.6.0 Released
                          posts)
    11. 18 Dec            (1      libsysfs 0.4.0 Released
                          post)
    12. 18 Dec            (1      x86_64-2.6.0-1 Released
                          post)
    13. 18 Dec            (1      Itanium Maintainership
                          post)

Introduction

 

1. Discussion Of Binary Modules; Linus Prefers OSL License To GPL
3 Dec  - 18 Dec  (276 posts) Archive Link: "Linux GPL and binary module
exception clause?"
Topics: Binary-Only Modules, FS: JFS
People: Kendall Bennett, Linus Torvalds, Jason Kingsland, Alan Cox

A lot of folks participated in this thread. Below are some small bits and
pieces.

Kendall Bennett started it off, saying:

    I have heard many people reference the fact that the although the Linux
    Kernel is under the GNU GPL license, that the code is licensed with an
    exception clause that says binary loadable modules do not have to be under
    the GPL. Obviously today there are vendors delivering binary modules (not
    supported by the kernel maintainers of course), so clearly people believe
    this to be true. However I was curious about the wording of this exception
    clause so I went looking for it, but I cannot seem to find it. I downloaded
    the 2.6-test1 kernel source code and looked at the COPYING file, but found
    nothing relating to this (just the note at the top from Linus saying user
    programs are not covered by the GPL). I also looked in the README file and
    nothing was mentioned there either, at least from what I could see from a
    quick read.

    So does this exception clause exist or not? If not, how can the binary
    modules be valid for use under Linux if the source is not made available
    under the terms of the GNU GPL?

    Lastly I noticed that the few source code modules I looked at to see if the
    exception clause was mentioned there, did not contain the usual GNU GPL
    preable section at the top of each file. IMHO all files need to have such a
    notice attached, or they are not under the GNU GPL (just being in a ZIP/tar
    achive with a COPYING file does not place a file under the GNU GPL). Given
    all the current legal stuff going on with SCO, I figured every file would
    have such a header. In fact some of the files I looked at didn't even
    contain a basic copyright notice!!

Linus Torvalds repied:

    No such exception exists.

    There's a clarification that user-space programs that use the standard
    system call interfaces aren't considered derived works, but even that isn't
    an "exception" - it's just a statement of a border of what is clearly
    considered a "derived work". User programs are _clearly_ not derived works
    of the kernel, and as such whatever the kernel license is just doesn't
    matter.

    And in fact, when it comes to modules, the GPL issue is exactly the same.
    The kernel _is_ GPL. No ifs, buts and maybe's about it. As a result,
    anything that is a derived work has to be GPL'd. It's that simple.

    Now, the "derived work" issue in copyright law is the only thing that leads
    to any gray areas. There are areas that are not gray at all: user space is
    clearly not a derived work, while kernel patches clearly _are_ derived
    works.

    But one gray area in particular is something like a driver that was
    originally written for another operating system (ie clearly not a derived
    work of Linux in origin). At exactly what point does it become a derived
    work of the kernel (and thus fall under the GPL)?

    THAT is a gray area, and _that_ is the area where I personally believe that
    some modules may be considered to not be derived works simply because they
    weren't designed for Linux and don't depend on any special Linux behaviour.

    Basically:

      + anything that was written with Linux in mind (whether it then _also_
        works on other operating systems or not) is clearly partially a derived
        work.
      + anything that has knowledge of and plays with fundamental internal
        Linux behaviour is clearly a derived work. If you need to muck around
        with core code, you're derived, no question about it.

    Historically, there's been things like the original Andrew filesystem
    module: a standard filesystem that really wasn't written for Linux in the
    first place, and just implements a UNIX filesystem. Is that derived just
    because it got ported to Linux that had a reasonably similar VFS interface
    to what other UNIXes did? Personally, I didn't feel that I could make that
    judgment call. Maybe it was, maybe it wasn't, but it clearly is a gray
    area.

    Personally, I think that case wasn't a derived work, and I was willing to
    tell the AFS guys so.

    Does that mean that any kernel module is automatically not a derived work?
    HELL NO! It has nothing to do with modules per se, except that non-modules
    clearly are derived works (if they are so central to the kenrel that you
    can't load them as a module, they are clearly derived works just by virtue
    of being very intimate - and because the GPL expressly mentions linking).

    So being a module is not a sign of not being a derived work. It's just one
    sign that _maybe_ it might have other arguments for why it isn't derived.

He replied to himself a few minutes later, to add:

    Side note: historically, the Linux kernel module interfaces were really
    quite weak, and only exported a few tens of entry-points, and really mostly
    effectively only allowed character and block device drivers with standard
    interfaces, and loadable filesystems.

    So historically, the fact that you could load a module using nothing but
    these standard interfaces tended to be a much stronger argument for not
    being very tightly coupled with the kernel.

    That has changed, and the kernel module interfaces we have today are MUCH
    more extensive than they were back in '95 or so. These days modules are
    used for pretty much everything, including stuff that is very much
    "internal kernel" stuff and as a result the kind of historic "implied
    barrier" part of modules really has weakened, and as a result there is not
    avery strong argument for being an independent work from just the fact that
    you're a module.

    Similarly, historically there was a much stronger argument for things like
    AFS and some of the binary drivers (long forgotten now) for having been
    developed totally independently of Linux: they literally were developed
    before Linux even existed, by people who had zero knowledge of Linux. That
    tends to strengthen the argument that they clearly aren't derived.

    In contrast, these days it would be hard to argue that a new driver or
    filesystem was developed without any thought of Linux. I think the NVidia
    people can probably reasonably honestly say that the code they ported had
    _no_ Linux origin. But quite frankly, I'd be less inclined to believe that
    for some other projects out there..

Jason Kingsland pointed out that if "mucking around with core code" made a work
derived, then "why the introduction of EXPORT_SYMBOL_GPL and MODULE_LICENSE()?
Specifying explicit boundaries for the module interface has legitimised
binary-only modules. This was the signal to developers of proprietary code that
binary-only modules are tolerable." He also gave a link to an article by Kevin
Dankwardt (http://www.linuxdevices.com/articles/AT5041108431.html) on the
subject. Linus replied that EXPORT_SYMBOL_GPL and MODULE_LICENSE were "really
just documentation." He went on:

    This is exactly so that it is more clear which cases are black-and-white,
    and where people shouldn't even have to think about it for a single second.
    It still doesn't make the gray area go away, but it limits it a bit ("if
    you need this export, you're clearly doing something that requires the
    GPL").

    Note: since the kernel itself is under the GPL, clearly anybody can modify
    the EXPORT_SYMBOL_GPL() line, and remove the _GPL part. That wouldn't be
    against the license per se. But it doesn't make a module that needs that
    symbol any less needful of the GPL - exactly because the thing is just a
    big cluehint rather than anything else.

Elsewhere, Linus added his judgement of the GPL and the OSL (Open Software
License) (http://opensource.org/licenses/osl-2.0.php) . Of the GPL, Linus said,
"It's a very solid license, and your rants about it have no basis in fact. I
personally actually like the OSL slightly better in the way it was written."

Elsewhere, Linus offered:

    a "binary linux kernel module" is a derived work of the kernel, and thus
    has to come with sources.

    But if you use those same sources (and _you_ wrote them) they do not
    contain any Linux code, they are _clearly_ not derived from Linux, and you
    can license and use your own code any way you want.

    You just can't make a binary module for Linux, and claim that that module
    isn't derived from the kernel. Because it generally is - the binary module
    not only included header files, but more importantly it clearly is _not_ a
    standalone work any more. So even if you made your own prototypes and tried
    hard to avoid kernel headers, it would _still_ be connected and dependent
    on the kernel.

    And note that I'm very much talking about just the _binary_. Your source
    code is still very much yours, and you have the right to distribute it
    separately any which way you want. You wrote it, you own the copyrights to
    it, and it is an independent work.

    But when you distribute it in a way that is CLEARLY tied to the GPL'd
    kernel (and a binary module is just one such clear tie - a "patch" to build
    it or otherwise tie it to the kernel is also such a tie, even if you
    distribute it as source under some other license), you're BY DEFINITION not
    an independent work any more.

    (But exactly because I'm not a black-and-white person, I reserve the right
    to make a balanced decision on any particular case. I have several times
    felt that the module author had a perfectly valid argument for why the
    "default assumption" of being derived wasn't the case. That's why things
    like the AFS module were accepted - but not liked - in the first place).

In the same post, he went on:

    This is why SCO's arguments are specious. IBM wrote their code, retained
    their copyrights to their code AND THEY SEVERED THE CONNECTION TO SCO'S
    CODE (and, arguably the connections didn't even exist in the first place,
    since apparently things like JFS were written for OS/2 as well, and the
    Linux port was based on that one - but that's a separate argument and
    independent of my point).

    See the definition of "derivative" in USC 17.1.101:

        A "derivative work" is a work based upon one or more preexisting works,
        such as a translation, musical arrangement, dramatization,
        fictionalization, motion picture version, sound recording, art
        reproduction, abridgment, condensation, or any other form in which a
        work may be recast, transformed, or adapted. A work consisting of
        editorial revisions, annotations, elaborations, or other modifications
        which, as a whole, represent an original work of authorship, is a
        "derivative work".

    And a binary module is an "elaboration" on the kernel. Sorry, but that is
    how it IS.

    In short: your code is yours. The code you write is automatically
    copyrighted by YOU, and as such you have the right to license and use it
    any way you want (well, modulo _other_ laws, of course - in the US your
    license can't be racist, for example, but that has nothing to do with
    copyright laws, and would fall under a totally different legal framework).

    But when you use that code to create an "elaboration" to the kernel, that
    makes it a derived work, and you cannot distribute it except as laid out by
    the GPL. A binary module is one such case, but even just a source patch is
    _also_ one such case. The lines you added are yours, but when you
    distribute it as an elaboration, you are bound by the restriction on
    derivative works.

    Or you had better have some other strong argument why it isn't. Which has
    been my point all along.

Elsewhere, Linus also said:

    personally, I have my own judgment on what "derivative works" are, and I
    use that judgement to decide if I'd complain or take the matter further.

    And so _I_ personally think some binary modules are ok, and you've heard my
    arguments as to why. That means that _I_ won't sue over such uses, since in
    my opinion there is no copyright infringement IN THOSE CASES due to me not
    considering them derivative.

    My opinions are fairly public, and the stuff I say in public actually does
    have legal weight in that it limits what I can do (if I say in public that
    I think something is ok, I have a much harder time then making the argument
    that it _isn't_ ok in front of a judge - this is what the "estoppel" thing
    is all about).

    But the thing is, my public opinions don't bind anybody else. So if Alan
    Cox, or _any_ other kernel copyright holder, disagrees with me (and trust
    me, people do), they have the right to complain on their own. Their case
    would be weakened by my stance (simply because a defendant could point to
    my opinions and the judge might be swayed by that).

    And quite frankly, my largest reason for not complaining loudly has often
    been that I'm lazy, and in several cases of sme people using GPL'd work
    improperly I have been ready to join a lawsuit that somebody else
    initiates. So far people have tended to back down.

Elsewhere, Linus also said:

    I'd like to make it clear that I'm actually much softer on this than many
    other people - I've been making it clear that I think that binary-only
    modules _are_ ok, but that the burden of proof of ok'ness is squarely on
    the shoulders of the company that makes them.

    So please do get that part clear: I'm pretty well-known for allowing
    binary-only modules in things like AFS and nVidia, where some people think
    they shouldn't be allowed.

    But the real issue here (and in the subject line in this whole discussion)
    is about an "exception clause".

    There is none. And I'm just saying that there is NO WAY that a binary-only
    module is "automatically in the clear". They _may_ be, but it's on the
    basis of something totally different than just "it's a module".

    This is why I want to make it so clear that "moduleness" (which is not a
    word, but should be one) is not the thing that matters. There's still a
    strong "linkage" to a particular kernel in a binary module, and the act of
    running the linker is not what determines whether a work is a derived work.

    In short, you should not see my arguments as a way of saying "all modules
    are derived works". I'm clearly not saying that, since I _do_ allow binary
    only modules and I don't claim they infringe.

    So I'm not arguing for a very wide notion of derived works: I'm arguing
    AGAINST the narrow notion that a module would somehow automatically _not_
    be derived.

    This is why I've said at least fifty times that a kernel module is to be
    considered "derived by default". The non-derivedness comes from things that
    have nothing to do with whether it is a module.

There was quite a long discussion, involving many interesting people who said
many interesting things.

 

2. Status Of DevFS/udev In 2.6
8 Dec  - 14 Dec  (107 posts) Archive Link: "State of devfs in 2.6?"
Topics: FS: devfs, FS: ramfs, FS: sysfs, Hot-Plugging
People: Andrew Walrond, William Lee Irwin III, Rob Landley, Greg KH

Andrew Walrond asked:

    Whats the general feeling about devfs now? I remember Christoph and others
    making some nasty remarks about it 6months ago or so, but later noted
    christoph doing some slashing and burning thereof.

    Is it 'nice' yet?

Greg KH said that the DevFS code was deprecated and suffered from unsolvable
race conditions; William Lee Irwin III also said to Andrew, "I would say it's
deprecated at the very least. sysfs and udev are supposed to provide equivalent
functionality, albeit by a somewhat different mechanism." Andrew thanked him
and asked how well the udev replacement for DevFS was doing; in particular, did
udev offer a viable MAKEDEV replacement. Rob Landley replied:

    My understanding is that udev takes the information exported by sysfs about
    what devices exist in the system, and creates device nodes in /dev (which
    can be a ramfs mount or part of a persistent filesystem, udev itself
    doesn't care). I'm guessing it traverses sysfs to see what the system's got
    on startup (some variant of "find /sys -name device", perhaps) and then
    receives hotplug events when new devices are added later. On the whole,
    this is generally cool, hotplug friendly, and small and simple. _and_ the
    result looks like a recognizable /dev directory, so end-user applications
    don't have to be "devfs aware" (which was a bad sign from day 1 if you ask
    me).

    Unfortunately, sysfs doesn't yet export device node information for
    everything in the system yet. (There aren't any under /sys/cdev, /sys/
    devices/legacy, or /sys/devices/system, for example). There are pending
    patches to add more, but they're not considered bug fixes, so Linus won't
    take them before 2.6.0 and we'll have to wait until after 2.6.0 for
    development on this subsystem to finish.

    Probably somewhere in the 2.6.4 to 2.6.6 timeframe, sysfs will have all the
    device exports udev needs. (Or at least all the ones anybody's complained
    about yet.) Until then... dunno. Maybe you can use a /dev directory on a
    persistent filesystem that you mknod any extra devices you need into
    yourself?)

 

3. Linux 2.4.24-pre1 Released; XFS Merged
10 Dec  - 12 Dec  (11 posts) Archive Link: "Linux 2.4.24-pre1"
Topics: FS: ReiserFS, FS: XFS, OOM Killer
People: Mike Fedyk, Marcelo Tosatti, Hans Reiser

Marcelo Tosatti announced 2.4.24-pre1, saying the XFS filesystem had been
merged. See Issue #244, Section #6  (30 Nov : Split XFS Patches For 2.4.23) for
the debate on this issue.

Mike Fedyk asked, "Will you accept the data-logging patches for reiserfs3 from
suse in this release if it is submitted? Don't forget that the OOM killer has
been added as an option (defaulting to off :)" Marcelo said, "Its up to the
reiserfs people." Hans Reiser replied, "I will approve it once Chris tells me
it is ready. (Especially since I asked him for the patch port....;-) )" And
Mike said, "Hasn't it been ready for a while now? Let's get the merging
started. :)"

 

4. New -tiny Kernel Patchset To Collect Patches That Shrink The Kernel
11 Dec  - 12 Dec  (7 posts) Archive Link: "[ANNOUNCE] -tiny tree for small
systems (2.6.0-test11)"
Topics: FS: sysfs, Networking, Small Systems
People: Matt Mackall, Tom Rini, Rom Rini, Bill Davidsen

Matt Mackall announced:

    This is the first release of a new kernel tree dubbed '-tiny' (someone
    already took -mm). The aim of this tree is to collect patches that reduce
    kernel disk and memory footprint as well as tools for working on small
    systems, an area Linux mainstream has been moving away from since Linus got
    a real job. Target users are things like embedded systems, small or legacy
    desktop folks, and handhelds.

    To get the ball rolling, I've thrown in about 50 patches that trim various
    bits of the kernel, almost all configurable, and a fair number may
    eventually be appropriate for mainline. All the config options are
    currently thrown under CONFIG_EMBEDDED and many of the minor tweaks are
    covered under a set of config options called CONFIG_CORE_SMALL,
    CONFIG_NET_SMALL, and CONFIG_CONSOLE_SMALL.

    Nifty things I've included:

      + building with -Os
      + 4k process stacks (via -wli)
      + configurable removal of printk, BUG, and panic() strings
      + configurable HZ
      + configurable support for vm86, core dumps, kcore, sysfs, aio, etc.
      + a very nice kmalloc auditing system via /proc/kmalloc
      + auditing of bootmem usage
      + a system for counting inline instantiations
      + my netpoll/netconsole patches
      + my drivers/char/random fixups

    Some items on my todo list:

      + borrow kgdb from -mm
      + merge my netpoll-based kgdb-over-ethernet
      + pageable kernel memory for a select subset of the kernel
      + reduced functionality vt for small gui systems
      + generic lookup/hash management code

    How small is -tiny? It's hard to quantify as it's all configurable and some
    functionality is more important than others, but my current test config has
    full IPv4 net stack and most other important functionality and will boot
    comfortably on a 4M x86 box with about 2M free+buffers+cache.

    Bug reports, suggestions, and patch submissions are welcome!

    The patch, currently against 2.6.0-test11, can be found at:

    http://selenic.com/tiny/

Tom Rini replied, "I'd like to suggest you check out the "tweaks" idea I tossed
out here: http://www.ussg.iu.edu/hypermail/linux/kernel/0211.0/2229.html If
this sounds interesting, I've got a version of the patch (albeit old and not
applying directly right now I bet) that moved things into header files and got
all of the dependancy stuff correct except for the initial run (so I think I
was forcing an update with any make invocation, but there were no spurious
recompiles)." Matt said, "Looks cool. My only worry is that to do it right, it
has to make some fairly sweeping changes. I'm trying to keep the stuff in -tiny
fairly small and independent so that stuff can be cherry-picked, but if we can
get a consensus that "tweaks" is a good direction for mainline, it might prove
useful for some of the stuff I'm doing with CONFIG_CORE_SMALL and friends now."
Tom replied, "part of the problem that came up when this was brought up during
2.5 is that adding a whole bunch of CONFIG options for things Just Won't Happen
(too complex, PITA, etc). OTOH however, lots of stuff like that keeps getting
in." And Bill Davidsen replied, "But now we have a config section for disabling
things which may not be needed in embedded systems. So there's a fair chance
that tweaks and such can be accepted as long as they're in the area where most
will never go." But Tom said this was also true when the question came up in
2.5.

 

5. Revised 'Unreliable' Kernel Locking Guide
11 Dec  - 15 Dec  (14 posts) Archive Link: "[DOCUMENTATION] Revised Unreliable
Kernel Locking Guide"
People: Rusty Russell

Rusty Russell announced:

    OK, I've put the html version up for your reading pleasure: the diff is
    quite extensive and hard to read.

    http://www.kernel.org/pub/linux/kernel/people/rusty/kernel-locking/

A bunch of folks were happy to see this, and offered corrections and
suggestions.

 

6. Larry Pulls Another Larry
14 Dec  - 21 Dec  (33 posts) Archive Link: "RFC - tarball/patch server in
BitKeeper"
Topics: Version Control
People: Larry McVoy, Larry McVoy , Pavel Machek

Larry McVoy announced:

    I've prototyped an extension to BitKeeper that provides tarballs and
    patches. The idea is to make it possible for all trees hosted by bkbits.net
    provide access to the data with a free client (included below in prototype
    form).

    The system is simplistic, it just provides a way to get the most recent
    sources as a tarball and then any later updates as a patch. There is no
    provision for generating diffs, editing files, merging, etc. All of that is
    something that you can write, if you want, using standard tools (think hard
    linked trees).

    Before rolling this out, I want to know if this is going to (finally) put
    to rest any complaints about BK not being open source, available on all
    platforms, etc. You need to understand that this is all you get, we're not
    going to extend this so you can do anything but track the most recent
    sources accurately. No diffs. No getting anything but the most recent
    version. No revision history.

    If you want anything other than the most recent version your choices are to
    use BitKeeper itself or, if you want the main branches of the Linux kernel,
    the BK2CVS exports. This is not a gateway product, it is a way for
    developers to track the latest and greatest with a free (source based)
    client. It is not a way to convert BK repos to $SCM.

    If the overwhelming response is positive then I'll add this to the
    bkbits.net server and perhaps eventually to the BK product itself.

Chris Frey and Pavel Machek drew attention to the license Larry used for the
software:

    Licensed under the NWL - No Whining License.

    You may use this, modify this, redistribute this provided you agree:

      + not to whine about this product or any other products from BitMover,
        Inc.
      + that there is no warranty of any kind.
      + retain this copyright in full.

 

7. Status Of CONFIG_USB_DC2XX In 2.6
14 Dec  (2 posts) Archive Link: "dc2xx.c ported yet?"
Topics: Hot-Plugging, USB
People: Joshua Kwan, David Ford

Joshua Kwan asked, "Hi, I noticed that CONFIG_USB_DC2XX is not available in the
2.6 tree and dc2xx.c doesn't exist either. However, it's available in 2.4. Does
the driver need to be ported? If so, can I help?" David Ford replied that there
was no need for a port. He said:

    It is accessed via libusb these days opening /proc/bus/usb/*/*

    Emerge (apt-get, etc, as per your distro of choice) something like gphoto2
    which should include libusb by dependancy and setup hotplug.

 

8. Update Of Experimental Net Driver
15 Dec  - 18 Dec  (4 posts) Archive Link: "[BK PATCHES] 2.6.x experimental net
driver updates"
Topics: Networking
People: Jeff Garzik, Stephen Hemminger, Adrian Bunk, Francois Romieu, Krzysztof
Halasa

Jeff Garzik announced:

    Another edition of net driver updates.

    Summary of new changes:

      + revert skfddi janitorial patches. no skfddi changes are included in
        this patchkit anymore. Stephen Hemminger has a much better skfddi patch
        which obsoleted the already-merged skfddi changes.
      + atmel wireless SKB leak fix
      + 3c574_cs deadlock fix
      + bonding destruction fix
      + more work from Al making net_device allocation dynamic and sane
        (including fast, const-offset private structure allocation for drivers)
      + sk98lin update from vendor
      + TG3 update from DaveM
      + new pc200syn WAN driver from WAN maintainer Krzysztof Halasa
      + r8169 fixes from Francois Romieu

    Summary of patchkit:

      + new e100 driver (rewritten from scratch)
      + new nVidia nForce NIC driver
      + new pc200syn WAN driver
      + tg3 bug fixes
      + r8169 major bug fixes
      + e1000 minor updates / fixes
      + sk98lin vendor updates / fixes
      + misc bug fixes
      + 8139too NAPI support
      + tulip NAPI support
      + netconsole / netdump support
      + net_device allocation and reference counting work

    Patch:
    http://www.kernel.org/pub/linux/kernel/people/jgarzik/patchkits/2.6/
    2.6.0-test11-bk11-netdrvr-exp1.patch.bz2

    Full changelog:
    http://www.kernel.org/pub/linux/kernel/people/jgarzik/patchkits/2.6/
    2.6.0-test11-bk11-netdrvr-exp1.log

    BK repo:
    bk://gkernel.bkbits.net/net-drivers-2.5-exp

After a bug report from Adrian Bunk, Jeff posted an updated patch (http://
www.kernel.org/pub/linux/kernel/people/jgarzik/patchkits/2.6/
2.6.0-test11-bk11-netdrvr-exp2.patch.bz2) and changelog (http://www.kernel.org/
pub/linux/kernel/people/jgarzik/patchkits/2.6/
2.6.0-test11-bk11-netdrvr-exp2.log) ; which Adrian confirmed worked for him.

 

9. Status Of -mm Tree And 2.6
17 Dec  - 19 Dec  (17 posts) Archive Link: "2.6.0-test11-mm1"
People: Andrew Walrond, Andrew Morton, Thomas Molina, Christian Axelsson

Andrew Morton put out 2.6.0-test11-mm1, and Andrew Walrond asked, "What are
your intentions with -mm when you take over 2.6? Is any of -mm getting into 2.6
before 2.6.0 release? Is it mainly queued for 2.6.1?" Christian Axelsson also
wanted to know, and Andrew M. replied, "We'll start merging it up after 2.6.0.
It'll be quite a lot of work, actually - a lot of things have been parked in
-mm for some time and may not have had sufficiently wide testing, especially on
non-i386. I need to ask the originators and others to re-review and retest some
things." Thomas Molina said he was concerned that the sheer quantity of stuff
queued for post-2.6.0 was becoming likely to make 2.6.1 much less stable than
2.6.0; and this worried him. But Andrew M. said that most of the stuff in the
queue represented real fixes for real problems, and that it was mainly just a
question of figuring out the best way to merge them all so the least breakage
would occur. He also suggested that folks do a lot of testing on the -mm tree,
since that was where new patches would go prior to each new 2.6 release.

 

10. Linux 2.6.0 Released
17 Dec  - 18 Dec  (47 posts) Archive Link: "Linux 2.6.0"
Topics: Big Memory Support, Bug Tracking, Disk Arrays: LVM, Disk Arrays: RAID, 
Disks: IDE, FS: ext2, SMP
People: Linus Torvalds, Andrew Morton, Trond Myklebust

Linus Torvalds announced:

    "The beaver is out of detox"
    - Anon

    This should not be a big surprise to anybody on the list any more, since
    we've been building up to it for a long time now, and for the last few
    weeks I haven't accepted any patches except for what amounts to fairly
    obvious one-liners.

    Anyway, 2.6.0 is out there now, and the patch from -test11 is a swelte 11kB
    in size. It's not the totally empty patch I was hoping for, but judging by
    the bugs I worked on personally, things are looking pretty good.

    To give you an example, one of the nastier bugs that we chased for the last
    five weeks was a bug that could only be reproduced reliably on a 16- or
    32-way system, and only when the system had flaky disks. Putting in
    known-good disks made the problem disappear. Similarly, compiling the
    kernel with another compiler made the problem disappear.

    It turned out to be a really subtle bug wrt SMP ordering and stack
    allocation, and lots of thanks to Ram Pai for gathering all the information
    that eventually led to it being fixed. The fix was a one-liner and a big
    comment - but my point is that the quality of bugs has been pretty high
    lately, and we feel that we're in pretty good shape.

    Andrew has written up some caveats and pointers to information about 2.4.x
    vs 2.6.x changes, and I'll let him post that. Some known issues were not
    considered to be release-critical and a number of them have pending fixes
    in the -mm queue. Generally they just didn't have the kind of verification
    yet where I was willing to take them in order to make sure a fair 2.6.0
    release.

    NOTE! I'll continue to keep track of the 2.6 BK tree until we're closer to
    the time when we literally split it for 2.7.x, because both Andrew and I
    are pretty comfortable with our respective toolchains. But Andrew is the
    stable tree maintainer, so everything should be approved by him at this
    point. Think of the -mm tree as the staging area, and mine as a release
    tree. We'll work together, but Andrew is boss.

    (BK merging will have to go through some approval format, we'll see how
    that works out exactly).

A multitude burst into applause across the world. Regarding Andrew Morton's
list of caveats, Andrew said:

    It's actually rather short because I started late. See below.

    There are also the "must-fix" and "should-fix" lists of items which we have
    identified as still on the 2.6 todo list. These are at

    ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/must-fix/must-fix-7.txt
    and ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/must-fix/
    should-fix-7.txt

      + The 2.6.0 kernel has undergone several weeks of stabilization and we
        expect it to run well on server-class machines.

        Desktops and laptops may have more trouble at this time because of the
        much wider range of hardware and because of as-yet unimplemented fixes
        for the hardware and BIOS bugs from which these machines tend to
        suffer.

        During the 2.6.0 stabilization period a significant number of less
        serious fixes have accumulated in various auxiliary kernel trees and
        these shall be merged into the 2.6 stream after the 2.6.0 release. Many
        of these fixes appear in Andrew Morton's "-mm" tree, at

        ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/

      + Please report any problems to the appropriate mailing list. If you do
        not know which list to use, send the report to
        [email protected] and it should reach the right person. Some
        active subsystem mailing lists are:

        [email protected]
        [email protected]
        [email protected]
        [email protected]
        [email protected]
        [email protected]

        Alternatively, kernel bug reports may be entered into the kernel bug
        tracking system at http://bugme.osdl.org/

      + There are significant changes in the module subsystem, the LVM (Device
        Mapper) and RAID subsystems. Details about these and many other kernel
        changes are presented in David Jones's kernel upgrade document at

        http://www.linux.org.uk/~davej/docs/post-halloween-2.6.txt

        Users who are testing 2.6 kernels for the first time should consult
        this document.

      + The ATA RAID drivers (eg the HighPoint RAID driver) have not been
        ported to the new BIO code and are not available under the 2.6 kernel
        at this time.
      + cryptoloop doesn't work on highmem machines. Fixes exist in -mm and are
        queued for 2.6.1.
      + There are known performance problems with the default disk I/O
        scheduler which show up when the workload is performing small, random
        reads and writes (ie: database loads). Largely fixed in -mm.

        In general, the "deadline" I/O scheduler is, and shall remain somewhat
        faster than the default "anticipatory" I/O scheduler with these sorts
        of workloads. Database admins should consider adding the "elevator=
        deadline" kernel boot parameter.

      + There are performance problems due to misbehaviour in the readahead
        code which also impact database-style workloads. Fixed in -mm, queued
        for 2.6.1.
      + There are a larger number of as-yet unmerged frame buffer driver fixes.

Trond Myklebust asked, "Will you be posting a plan for how you want the 2.6.x
series to proceed? I gather I'm not alone in having a load of patches that I'd
like to send you ASAP..." Andrew replied:

    I believe that the processes we've all been using for the past year have
    worked well (invitation here for people to disagree). So any changes we
    make to that process shouldn't be arbitrary.

    I expect that until 2.7.0 forks, Linus and I shall continue to work 2.6.x
    in much the same manner - that's what I'd prefer, anyway.

    Obviously, the threshold for merging things into 2.6 becomes higher, and
    large changes will be rejected pending more review and testing. I shall
    continue to run an alternate tree for the provision of that testing
    service.

    Generally, we should expect that there will be large changes across the 2.6
    lifetime - it is unrealistic to believe otherwise. We just need to find the
    processes to absorb those changes (and feed them into or from 2.7.x)
    without breaking stuff. We've done that fairly well across 2.5 I think.

    We should sit tight for the next week or so, in case we need to rush out a
    2.6.1 for brown-bag bugs. After that I need to shrink the -mm patchset
    rather a lot.

 

11. libsysfs 0.4.0 Released
18 Dec  (1 post) Archive Link: "[ANNOUNCE] libsysfs v0.4.0"
Topics: FS: devfs, FS: sysfs, Klibc
People: Ananth N Mavinakayanahalli

Ananth N Mavinakayanahalli announced:

    Release 0.4.0 for libsysfs is now available at:

    http://linux-diag.sourceforge.net

    A number of changes have been made in this release which will require a few
    modifications to applications already using the library. (udev-009 already
    has a bulk of these changes).

    Here are the important additions/changes:

      + Postponed reading directories and attributes until absolutely
        necessary.
      + Structure elements that are lists or references to structures are not
        populated by default. APIs have now been provided to populate them.
      + All "open" functions that take absolute path as argument now have a
        "_path" suffix.
      + Provided attribute "refresh" functions to read in updated attribute
        values.
      + Changes for klibc compatibility.
      + Provided APIs to retrieve device/class_device "parent".
      + Added manpages for lsbus and systool (Thanks to Martin Pitt).

    Please visit http://linux-diag.sourceforge.net/Sysfsutils.html for more
    information.

 

12. x86_64-2.6.0-1 Released
18 Dec  (1 post) Archive Link: "x86_64-2.6.0-1 released"
Topics: Executable File Format, FS: JFS, FS: sysfs, Power Management: ACPI, SMP
, Serial ATA
People: Andi Kleen

Andi Kleen announced:

    The first x86-64 patchkit for the 2.6.0 linux kernel has been released. I
    normally don't announce patchkits to linux-kernel, but a lot of people
    don't seem to know about them. The patchkit has fixes for many serious bugs
    (including data corruption iossues) on x86-64 that didn't make it in
    official 2.6.0. Please don't bother reporting any x86-64 problems to me if
    you didn't apply the patchkit first.

    Hopefully now that the trees are more open again most of this can migrate
    into the official tree, depending on the policy enforced by Linus/Andrew.

    This version just has a few minor fixes against the last patchkit release
    (x86_64-2.6.0test11-3)

    ftp://ftp.x86-64.org/pub/linux/v2.6/x86_64-2.6.0-1.bz2
    df65fee5a0388a036d324cb9b16bd778 x86_64-2.6.0-1.bz2

    ChangeLog since x86_64-2.6.0test11-3:

      + Mark some more non 64bit clean drivers !64BIT
      + Remove dump_sg in pci-gart.c again
      + Fix inefficiency in find_next_bit

    Older Changelog is available in

    ftp://ftp.x86-64.org/pub/linux/v2.6/RELEASE-NOTES

    Some known issues:

      + Taskfile IO can hang SuSE hwscan. Better disable it for now.
      + Taskfile IO can cause disk corruption too.
      + NMI watchdog runs too often (HZ instead once a second) (still true?) [I
        think that's fixed now, but needs verifying]
      + Machine Check calls printk currently, but that can deadlock when the
        MCE occurs inside any of the console locks.
      + sysfs support for arch/ may not be complete.
      + 32bit SYSCALL seems to still have problems with some programs (disabled
        currently)
      + Some reports of persistent segfaults after stress tests (also seen once
        here, need to be reproduced). Could be IOMMU overflow.
      + Mysterious timer bug in some cases. Shortly in or after bootup the
        timer lists gets corrupted in some configuration. Seems to depend on
        how long the bootup takes.
      + JFS seems to corrupt file systems quickly (generic 64bit bug)
        [maintainer cannot reproduce it]
      + WCHAN seems to be broken
      + Suspend often doesn't initialize video after wakeup Generic problem,
        needs a lot of effort to fix properly. The graphic card has to be
        POSTed properly, which is quite complicated.
      + MPT fusion driver breaks when iommu merging is disabled (run with iommu
        =merge) A workaround for this is enabled by default now. Underlying bug
        still unfixed. This bug seems to only occur on some specific machines,
        most MPT fusion users probably don't have to worry about it. Seems to
        be a driver bug.
      + Realtek 8169 driver does not support >4GB (patch exists, should be
        merged by network driver maintainer)
      + Nvidia and VIA boards are forced to IO-APIC off to work around ACPI
        bugs. This will be a major problem once SMP boards with these chipsets
        are out.
      + Some boards don't set the wall clock correctly
      + G400 DRM crashes machine
      + VIA SATA doesn't work
      + Some people report disk corruptions with IOMMU. Not able to reproduce
        it. It seems to happen on some block device drivers who have a very
        deep queue. Mostly these devices don't need an IOMMU (3ware is a
        prominent exception) because they support 64bit IO. Unfortunately many
        people still run with CONFIG_IOMMU_DEBUG which will force the IOMMU
        support for every device. Changing the IOMMU flush to flush on every
        mapping seems to fix it. Currently there are workarounds active that
        check for Qlogic and 3ware and do that. Anybody still seeing this
        please try with iommu=fullflush and report back. Underlying bug still
        undebugged.
      + Scheduler does not work well with NUMA (testcase multithreaded STREAM)
        It does not distribute threads quickly enough to all CPUs, which leads
        to memory getting allocated on the wrong nodes.
      + Some motherboard/cpu combinations do not reboot automatically
      + IPSec netlink setup code is not 32bit emulation clean
      + iptables is not 32bit emulation clean
      + gettimeofday gets non monontonous when ntpd corrects drift
      + valgrind does not run even with linux32 --3gb. Figure out what is
        different.
      + [An a.out emacs also doesn't run. Probable the same difference]

 

13. Itanium Maintainership
18 Dec  (1 post) Archive Link: "[PATCH] update sn2 MAINTAINERS file entry"
People: Jesse Barnes, John Hesterberg

Jesse Barnes posted a patch listing himself as the "SN-IA64 (Itanium)
SUB-PLATFORM" maintainer, instead of John Hesterberg.

 

 

 

 

 

 

                       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.