Kernel Traffic
Latest | Archives | People | Topics
Wine
Latest | Archives | People | Topics
GNUe
Latest | Archives | People | Topics
Czech
Home | News | RSS Feeds | Mailing Lists | Authors Info | Mirrors | Stalled Traffic
 

Kernel Traffic #246 For 26 Dec 2003

By Zack Brown

Table Of Contents

Introduction

1. Discussion Of Binary Modules; Linus Prefers OSL License To GPL

3 Dec 2003 - 18 Dec 2003 (276 posts) Archive Link: "Linux GPL and binary module exception clause?"

Topics: Binary-Only Modules, FS: JFS

People: Kendall BennettLinus TorvaldsJason KingslandAlan 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:

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 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). 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 2003 - 14 Dec 2003 (107 posts) Archive Link: "State of devfs in 2.6?"

Topics: FS: devfs, FS: ramfs, FS: sysfs, Hot-Plugging

People: Andrew WalrondWilliam Lee Irwin IIIRob LandleyGreg 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 2003 - 12 Dec 2003 (11 posts) Archive Link: "Linux 2.4.24-pre1"

Topics: FS: ReiserFS, FS: XFS, OOM Killer

People: Mike FedykMarcelo TosattiHans Reiser

Marcelo Tosatti announced 2.4.24-pre1, saying the XFS filesystem had been merged. See Issue #244, Section #6  (30 Nov 2003: 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 2003 - 12 Dec 2003 (7 posts) Archive Link: "[ANNOUNCE] -tiny tree for small systems (2.6.0-test11)"

Topics: FS: sysfs, Networking, Small Systems

People: Matt MackallTom RiniRom RiniBill 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:

Some items on my todo list:

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 2003 - 15 Dec 2003 (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 2003 - 21 Dec 2003 (33 posts) Archive Link: "RFC - tarball/patch server in BitKeeper"

Topics: Version Control

People: Larry McVoyPavel 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:

7. Status Of CONFIG_USB_DC2XX In 2.6

14 Dec 2003 (2 posts) Archive Link: "dc2xx.c ported yet?"

Topics: Hot-Plugging, USB

People: Joshua KwanDavid 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 2003 - 18 Dec 2003 (4 posts) Archive Link: "[BK PATCHES] 2.6.x experimental net driver updates"

Topics: Networking, Version Control

People: Jeff GarzikStephen HemmingerAdrian BunkFrancois RomieuKrzysztof Halasa

Jeff Garzik announced:

Another edition of net driver updates.

Summary of new changes:

Summary of patchkit:

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 and changelog; which Adrian confirmed worked for him.

9. Status Of -mm Tree And 2.6

17 Dec 2003 - 19 Dec 2003 (17 posts) Archive Link: "2.6.0-test11-mm1"

People: Andrew WalrondAndrew MortonThomas MolinaChristian 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 2003 - 18 Dec 2003 (47 posts) Archive Link: "Linux 2.6.0"

Topics: Big Memory Support, Bug Tracking, Device Mapper, Disk Arrays: LVM, Disk Arrays: RAID, Disks: IDE, FS: ext2, Kernel Release Announcement, SMP, Version Control

People: Linus TorvaldsAndrew MortonTrond Myklebust

Linus Torvalds announced Linux 2.6.0, saying:

"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

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 2003 (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:

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

12. x86_64-2.6.0-1 Released

18 Dec 2003 (1 post) Archive Link: "x86_64-2.6.0-1 released"

Topics: Executable File Format, FS: JFS, FS: sysfs, PCI, 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:

Older Changelog is available in

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

Some known issues:

13. Itanium Maintainership

18 Dec 2003 (1 post) Archive Link: "[PATCH] update sn2 MAINTAINERS file entry"

People: Jesse BarnesJohn Hesterberg

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

 

 

 

 

 

 

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.