I see no real reason to call it 3.0.

The order-of-magnitude threading improvements might just come closest to being a "new thing", but yeah, I still consider it 2.6.x. We don't have new architectures or other really fundamental stuff. In many ways the jump from 2.2 -> 2.4 was bigger than the 2.4 -> 2.6 thing will be, I suspect.

But hey, it's just a number. I don't feel that strongly either way. I think version number inflation (can anybody say "distribution makers"?) is a bit silly, and the way the kernel numbering works there is no reason to bump the major number for regular releases.

i consider the VM and IO improvements one of the most important things that happened in the past 5 years - and it's definitely something that users will notice. Finally we have a top-notch VM and IO subsystem (in addition to the already world-class networking subsystem) giving significant improvements both on the desktop and the server - the jump from 2.4 to 2.5 is much larger than from eg. 2.0 to 2.4.

I think due to these improvements if we dont call the next kernel 3.0 then probably no Linux kernel in the future will deserve a major number. In 2-4 years we'll only jump to 3.0 because there's no better number available after 2.8. That i consider to be ... boring :) [while kernel releases are supposed to be a bit boring, i dont think they should be _that_ boring.]

Hey, _if_ people actually are universally happy with the VM in the current 2.5.x tree, I'll happily call the dang thing 5.0 or whatever (just kidding, but yeah, that would be a good enough reason to bump the major number).

However, I'll believe that when I see it. Usually people don't complain during a development kernel, because they think they shouldn't, and then when it becomes stable (ie when the version number changes) they are surprised that the behabviour didn't magically improve, and _then_ we get tons of complaints about how bad the VM is under their load.

Am I hapyy with current 2.5.x? Sure. Are others? Apparently. But does that mean that we have a top-notch VM and we should bump the major number? I wish.

The block IO cleanups are important, and that was the major thing _I_ personally wanted from the 2.5.x tree when it was opened. I agree with you there. But I don't think they are major-number-material.

Anyway, people who are having VM trouble with the current 2.5.x series, please _complain_, and tell what your workload is. Don't sit silent and make us think we're good to go.. And if Ingo is right, I'll do the 3.0.x thing.

Actually current IPv6 is stable and has been for a long time, it's just not completely standards compliant (but still quite usable for a lot of people)

If you mean stable implies the latest whizbang features you have a different meaning of stable than me.

"Stick to"? We've never had that as any criteria for major numbers in the kernel. Binary compatibility has _never_ been broken as a release policy, only as a "that code is old, and we've given people 5 years to migrate to the new system calls, the old ones are TOAST".

The only policy for major numbers has always been "major capability changes". 1.0 was "networking is stable and generally usable" (by the standards of that time), while 2.0 was "SMP and true multi-architecture support". My planned point for 3.0 was NuMA support, but while we actually have some of that, the hardware just isn't relevant enough to matter.

The memory management issues would qualify for 3.0, but my argument there is really that I doubt everybody really is happy yet. Which was why I asked for people to test it and complain about VM behaviour - and we've had some ccomplaints ("too swap-happy") although they haven't sounded like really horrible problems.

I noticed Larry recently changed the license on bk. Once clause in particular struck me and I thought I'd better point it out for your reactions...

Specifically from Section 3:

(d) Notwithstanding any other terms in this License, this License is not available to You if You and/or your employer develop, produce, sell, and/or resell a product which contains substantially similar capabil- ities of the BitKeeper Software, or, in the reason- able opinion of BitMover, competes with the BitKeeper Software.

Doesn't this affect maintainers all across the map that work for distros such as RedHat, SuSE, Connectiva, etc? Obviously these distros SELL as part of their respective products CVS and similar tools. Or even non-distro open source shops, you even resell CVS or the like in some way and you'd be in trouble.

Larry, I develop for the Subversion project. Does that mean my license to use bitkeeper is revoked?

I've also been wanting to use bitkeeper to create a Subversion mirror of the kernel repository, but I suspect that my usage falls seriously into this category, as my reasons for doing so are three-fold; allow access to the bkbits repo to folks who don't want to use bk, but with all the joys of an SCM (history, changesets, etc.); stress test Subversion against a real-world high-activity repo; promote Subversion.

Would it be your intention that your license disallow my type of work? I think it does.

this kind of sudden change in Larry's written opinion within 24 hours is what makes this whole issue dangerous. Fact is that Larry is free to license his product under fair or unfair terms - it's his. While we already gave BK/BM tons of feedback, free beta-testing and free publicity, all we have is this volatile promise that the binary bits of BK are going to remain licensed - and with every day it will be harder and harder to move the repository.

what happens if Linux merges some sort of kernel based versioned filesystem, eg. something similar to what ClearCase does today? Will the license suddenly change to 'as long as you do not work on the versioned-FS kernel subsystem'? Or isnt this already a violation of the current license?

this is why i'd rather want to have an iron-clad legal way out first, and not have to rely on nonbinding promises done on public lists. I'm sure Larry understands this position, he has exactly the same position when trying to protect his business against hordes of freebies.

Larry, a simple question: does the BK license allow the Rational kernel developers to use BK (to eg. check out Linus' tree) when working on kernel support for ClearCase?

ie. is all kernel development activity against your license as long as the activity is a competitor of yours?

Now, other more serious kernel developers who have been using BK for some time, may one day find they'd like to help a competing project. They have to make a choice between the means that they develop for the linux kernel and helping a project they have become interested in.

Suddenly all the kernel developers who have staked their work in BK cannot work on a "competing" product to BK, without changing their development model.

Not only this, it gets worse.

In my case it is almost impossible to not get involved in many many free software projects. gettext or i18n in general, of glibc related issues pop up everywhere and often I contribute patches. Subversion is one of the projects where this has been the case in the past.

According to my understanding this means I'm tainted (I've asked Larry for confirmation).

Now the important part: I still have to work closely with kernel developers. The npt work is one example: I had to check out Ingo latest patches in the kernel every day. Now this isn't possible anymore without

1. me finding another route to get the latest kernel in realtime (which still could be considered illegal since somebody else, for the expressed purpose of making the result available to me, is using bk);
2. the kernel developers I work with not depending on bk anymore.

The second point is what is causing the trouble. Any team which wants to use bk to synchronize the work is tainted by one single individual being tainted.

I have never looked closer at bk than I had to be able to check out the latest sources. I'm not doing any development with it and I'm not checking in anything using bk.

People can grab the repository for use with CSSC from:

ftp://nl.linux.org/pub/linux/bk2patch/

Or using rsync:
rsync -rav --delete nl.linux.org::kernel/linux-2.4 linux-2.4
rsync -rav --delete nl.linux.org::kernel/linux-2.5 linux-2.5

Currently these repositories are updated every two hours, but if there is a large demand I could update it every hour or even every 30 minutes. Don't feel ashamed to put the above rsyncs into your crontabs, grab the source and use it ;)

Now that feature freeze is just around the corner I would like to ask you if we will get support for packet writing in the 2.6/3.0 kernel. It would be especialy nice to have support for Mount Rainier which enables easy use of CD-RWs and that would help people (especially newbies) that use CD-RWs a lot.

There are some patches from Jens Axboe that are available here: http://w1.894.telia.com/~u89404340/patches/packet/2.5/

Are patches these OK for this or would support have to be completely rewriten?

Well I have pressed the various legal departments in Mt-Rainer, and as long as we do not attempt to do non-native operations we should be clear.

Specifically legal, no license required :

MRW device and MRW media read/write is cool
MRW device format and create GAA, to create MRW from CDRW.

Specifically illegal, without a license agreement :

CDRW reading MRW media.
Building applications to stuff into the GAA to perform above.

These are key points, and the working group core has been blind cc'd.

Procps is the package containing various system monitoring tools, like ps, top, vmstat, free, kill, sysctl, uptime and more. After a long period of inactivity procps maintenance is active again and suggestions, bugreports and patches are always welcome on the procps list.

The plan is to release a procps 2.1.0 around the time the 2.6.0 kernel comes out, with regular releases until then. Code cleanups and all kinds of enhancements are welcome.

You can download procps 2.0.10 from:

http://surriel.com/procps/procps-2.0.10.tar.bz2

If you have feedback (or patches) for the procps team, feel free to mail us at:

procps-list@redhat.com

NEWS for version 2.0.10 of procps

• fix memory size overflow in ps (Anton Blanchard)
• add iowait statistics to top (Rik van Riel)
• update top help text (Denis Vlasenko)
• fix jumpy percentage formatting in top (Denis Vlasenko)
• fix some newer gcc compiler warnings (Denis Vlasenko)
• by default, do not show threads in ps or top - you can use the `-m' flag in ps or the `H' key in top to show them (Robert Love)

Simple: Albert's one is, well, Albert's. If it gets into sarge, procps gets on hold on my boxen, so I'm not too concerned...

I would (read: will) go with Rik's variant - unlike Albert he got taste. YMMV.

Albert Cahalan's procps seems to be focussed on rewriting and improving procps.

The procps project I'm maintaining is more focussed on supporting the latest stats exported by 2.5. I hope to get some time to clean up the source code, too...

Contrary to popular belief, procps is maintained. Craig Small, Jim Warner, and I have kept it up to date for several years now. Now I see that keeping a low profile is really bad, so here goes...

Changes that you may be unaware of and/or need:

top: windows, color, sort any field, 2.5.xx kernel support
sysctl: supports the VLAN interfaces
ps: runs 2x faster than procps-2.x.x did
vmstat: 2.5.xx kernel support

Get it here:
http://procps.sf.net/

We use procps-feedback@lists.sf.net for feedback and procps-news@lists.sf.net for announcements.

Here goes pre10.

This version fixes the NFS hang which was introduced in early 2.4.20-pre's plus some smaller fixes.

At http://www.xs4all.nl/~zippel/lc/ you can find the latest version of the new config system.

As already mentioned before lkc is pretty much ready (except for kbuild integration).

Linus, do you have any interest in merging it in the near future? If not, what's missing?

The 2.5.40 release showed again, how bad three different parsers are, so I think it's important to fix this finally for 2.6.

Changes this time:

• update to 2.5.41
• better error handling
• I introduced a few automaticly defined symbols (currently ARCH, KERNELRELEASE, UNAME_RELEASE), which are currently only used for the default location of the default config (e.g. "/boot/config-$UNAME_RELEASE" or "arch/$ARCH/defconfig"), which are currently still hardcoded, but could later be moved into Build.conf.
• more fine tuning
• I had to use my own Makefile again (Rules.make is slowly driving me insane).

I'm not super-excited about this, partly because of the brouhaha last time around on this issue.

This has reasonably distributed config files, and puts the help with the config entry where it belongs. Good. It also makes do with just standard unix tools, which is going to avoid one particular rat-hole, and which makes me at least understand the code. Also good.

Too ugly. I actually think QT is a fine choice, I just suspect that it's going to cause political issues.

My favourite approach by far is to actually not ship anything graphical with the kernel at all, and just hope that the config language syntax is stable enough that different groups can do their own as external packages.

The kernel would ship with just the text-based "reference implementation" (if even that - we could just have a few "supporting packages").

The only thing I personally really care about is the Config language, since that _has_ to ship with the kernel.

Here's a wonderful patch that I know you're all dying for... Memory Binding! It works just like CPU Affinity (binding) except that it binds a processes memory allocations (just buddy allocator for now) to specific memory blocks.

I've sent this out in the past, but haven't touched it in months.

Since the feature freeze is rapidly approaching, I want to get this out there again and see if anyone has any interest in it.

It's a fairly large patch, mostly because it includes a few odds and ends that are topology related, and don't strictly belong in this patch, but are pre-requisites for it (ie: the [memblk|node]_online_map stuff, and some of the cleanups to page_alloc). I'll probably try and break it up into more discrete parts very soon.

url: http://www.zip.com.au/~akpm/linux/patches/2.5/2.5.41/2.5.41-mm2/

• The per-cpu pages patches continue to disgrace themselves. Improvements in some microbenchmarks range from moderate (2%) to stunning (60%) but we're seeing a consistent few-percent regression in tests which perform networking to localhost. Heads continue to be scratched. This is irritating because that code is supposed to be the foundation for a page reservation API which fixes the radix-tree and pte_chain allocation failure problems.

  Ingo's original per-cpu-pages patch was said to be mainly beneficial for web-serving type things, but no specweb testing has been possible for a week or two due to oopses in the timer code.

• David McCracken's shared pagetable implementation is included - it is configurable on or off under the "Processor type and features" menu.
• The swappiness control code seems to be working well.

i sent my latest timer patch to Dave Hansen but have not heard back since. I've attached the latest patch, this kernel also printks a bit more when it sees invalid timer usage.

in any case, the oops Dave was seeing i believe was fixed by Linus (the PgUp fix), and it was in the keyboard code. If there's anything else still going on then the attached patch should either fix it or provide further clues.

So, you are new to Linux kernel hacking and want to submit a kernel bug report or a patch but don't know how to do it and _where_ to report it?

Preparing bug report:
=====================
*** Remember: bad/incomplete bug report ONLY wastes bandwidth! ***
How To Ask Questions The Smart Way:
    http://www.tuxedo.org/~esr/faqs/smart-questions.html
        Anybody who has written software for public use will
        probably have received at least one bad bug report.
        Reports that say nothing ("It doesn't work!");
        reports that make no sense; reports that don't give
        enough information; reports that give wrong information.
How to Report Bugs Effectively:
    http://www.chiark.greenend.org.uk/~sgtatham/bugs.html
        Before asking a technical question by email, or in
        a newsgroup, or on a website chat board, do the following:
        * Try to find an answer by searching the Web.
        * Try to find an answer by reading the manual.
        * Try to find an answer by reading a FAQ.
        * Try to find an answer by inspection or experimentation.
        * Try to find an answer by reading the source code.
Compile problems: report GCC output and result of "grep '^CONFIG_' .config"
Oops: decode it with ksymoops.
Unkillable process: Alt-SysRq-T and ksymoops relevant part.
Yes it means you should have ksymoops installed and tested,
which is easy to get wrong. I've done that too often.

Sending bug report/patch:
=========================
* Some device drivers have active developers, try to contact them first.
* Otherwise find a subsystem maintainer to which your report pertains
  and send report to his address.
* Small fixes and device driver updates are best directed to subsystem
  maintainers and "small bits" integrators.
* It never hurts to CC: Linux kernel mailing list, but without specific
  maintainer address in To: field there is high probability that your
  patch won't be noticed. You have been warned.
* Do not send it to all addresses at once! This will annoy lots of people
  and isn't useful at all. It's a spam.
* Do NOT send small fixes to Linus, he just can't handle _everything_.
  He will eventually receive it from maintainers/integrators, send it
  their way.
* If your patch is something big and new, announce it on lkml and try
  to attract testers. After it has been tested and discussed, you can
  expect Linus to consider inclusion in mainline.


                Current Linux kernel people

Note that this list is sorted in reversed date order, most recent
entries first. This means than entries at bottom can be outdated :-(


Linux kernel mailing list <linux-kernel@vger.kernel.org>
        Post anything related to Linux kernel here, but nothing else :-)

Andre Hedrick <andre@linux-ide.org> [02 oct 2002]
        ATA/ATAPI Storage Architect [2.0,2.2,2.4,2.5]
        HBA interface developer
        Serial ATA Architect [future release]
        Voting NCITS member AT-Attachment Committee

Jeff Garzik <jgarzik@mandrakesoft.com> [24 sep 2002]
        I am the network-card-drivers guy (8139 for instance).
        CC me and Andrew Morton <akpm@zip.com.au> on network driver patches.

Jan-Benedict Glaw <jbglaw@lug-owl.de> [18 sep 2002]
        I'm responsible for Alpha's srm_env driver, providing access to
        SRM's firmware variables.

Stuart MacDonald <stuartm@connecttech.com> [13 sep 2002]
        Connect Tech's linux kernel guy. Currently includes hacking on
        drivers/char/serial.c (Blue Heat, Xtreme, Dflex) and maintaining
        drivers/usb/serial/whiteheat.c (WhiteHEAT)

Vojtech Pavlik <vojtech@ucw.cz> [13 sep 2002]
        Feel free to send me bug reports and patches to input device drivers
        (drivers/input/*, drivers/char/joystick/*)
        I also want to receive bug reports and patches for following
        USB drivers: printer, acm, catc, hid*, usbmouse, usbkbd, wacom.
        All other (not in the list) USB driver changes should go to USB
        maintainer (hopefully there is one listed here :-).
        Also CC me if you are posting VIA IDE driver related message
        (although I am not IDE subsystem maintainer).

Robert Love <rml@tech9.net> [12 sep 2002]
        Preemptible kernel maintainer.
        I am also interesting in anything related to scheduling or locking
        primitives.

Jan Kara <jack@suse.cz> [22 aug 2002]
        quota subsystem maintainer

Paul Larson <plars@linuxtestproject.org> [20 aug 2002]
        I'm a maintainer for the Linux Test Project and it would be nice
        if people knew to send their test programs, etc. to me.  I see
        a lot of them flying around on lkml and try to catch them when
        I can, but it's a lot to keep up with.  It would be even better
        if people just knew to send them our way so we could clean
        them up and put them in LTP for regression testing.

Dave Engebretsen <engebret@vnet.ibm.com> [15 aug 2002]
        PPC64 architecture maintainer.  Please send PPC64 patches to me
        and our mailing list at <linuxppc64-dev@lists.linuxppc.org>

Ingo Molnar <mingo@elte.hu> [30 jul 2002]
        Ingo wrote the new scheduler for 2.5.

Ralf Baechle <ralf@uni-koblenz.de> [30 jul 2002]
        I am maintainer of the AX.25 code

Victor Yodaiken <yodaiken@fsmlabs.com> [30 jul 2002]
        RTLinux patches, updates, contributions, drivers.
        Please send first to the list: rtl@rtlinux.org

Pavel Machek <pavel@ucw.cz> [27 jul 2002]
        I am network block device maintainer. Visit http://nbd.sf.net.
        (see Steven Whitehouse <steve@gw.chygwyn.com> entry)
        I am working on software suspend.

William Irwin <wli@holomorphy.com> [02 jul 2002]
        Send bug reports and/or feature requests related to many tasks,
        rmap, space consumption, or allocators to me. I'm involved in
        * rmap
        * memory allocators
        * reducing space consumed by data structures (e.g. struct page)
        * issues arising in workloads with many tasks
        * kernel janitoring
        See also:
        Rik van Riel <riel@surriel.com>
        Andrea Arcangeli <andrea@suse.de>
        Martin Bligh <Martin.Bligh@us.ibm.com>
        Andrew Morton <akpm@zip.com.au>

Dave Jones <davej@suse.de> [23 apr 2002]
        I collect various bits and pieces for inclusion in 2.5,
        especially small and trivial ones and driver updates.
        I'll feed them to Linus when (and if) they
        are proved to be worthy.

Andrea Arcangeli <andrea@suse.de> [28 mar 2002]
        Send VM related bug reports and patches to me.
        I'm especially interested in VM issues with:
        * lots of RAM and CPUs
        * NUMA
        * heavy swap scenarios
        * performance of I/O intensive workloads (in particular
          with lots of async buffer flushing involved)
        See also Martin J. Bligh <Martin.Bligh@us.ibm.com> entry
        Mail also:
        Arjan van de Ven <arjanv@redhat.com>

Martin J. Bligh <Martin.Bligh@us.ibm.com> [28 mar 2002]
        I'm interested in VM issues with lots (>4G for i386)
        of RAM, lots of CPUs, NUMA

Steven Whitehouse <steve@chygwyn.com> [27 mar 2002]
        I am the Linux DECnet network stack maintainer
        Visit http://www.chygwyn.com/decnet/

Arnaldo Carvalho de Melo <acme@conectiva.com.br> [26 mar 2002]
        IPX, 802.2 LLC, NetBEUI, http://kerneljanitors.org,
        cyclom2x sync card driver

John Cagle <jcagle@kernel.org> [19 mar 2002]
        The current maintainer of devices.txt, the list of
        assigned device numbers for LANANA.  Consult the web
        site (www.lanana.org) for instructions on submitting
        requests for new device numbers.  Send all device
        related email to <device@lanana.org>.

Tigran Aivazian <tigran@veritas.com>
        I am author and maintainer of BFS filesystem and IA32
        microcode update driver.

Rogier Wolff <R.E.Wolff@BitWizard.nl> [12 mar 2002]
        I do "specialix serial ports":
        drivers/char/specialix.c (IO8+)
        drivers/char/sx.c        (SX, SI, SIO)
        drivers/char/rio/*.c     (RIO)

Martin Dalecki <martin@dalecki.de> [11 mar 2002]
        IDE subsystem maintainer for 2.5
        (mail Vojtech Pavlik <vojtech@suse.cz> too)

Ed Vance <serial24@macrolink.com> [05 mar 2002]
        Maintainer for the generic serial driver, serial.c,
        for 2.2 and 2.4 kernels.  Please post patches to
        linux-serial@vger.kernel.org for tested bug
        fixes or to add support for a new serial device.
        Limited to time available. If I have not responded
        in a week, yell at serial24@macrolink.com

netfilter/iptables development <netfilter-devel@lists.samba.org> [23 feb 2002]
        Please report all netfilter/iptables related problems
        to this mailinglist, where all netfilter developers are present.
        See also http://www.netfilter.org/contact.html

Hans Reiser <reiser@namesys.com> [16 feb 2002]
        Send me all reiserfs related patches with a cc to
        reiserfs-dev@namesys.com, send bug reports to
        reiserfs-dev@namesys.com, send paid support requests to
        support@namesys.com after going to www.namesys.com/support.html
        to pay, send discussions (not bug reports unless they are
        interesting to most persons) to reiserfs-list@namesys.com.
        If we sit on your patch for a week without responding,
        yell at us, we deserve it.  Look at our web page
        at www.namesys.com for more about sending us code,
        working with us, and our patch submission and tracking system.

Paul Bristow <paul@paulbristow.net> [16 feb 2002]
        I am an ide-floppy driver maintainer
        (ATAPI ZIP, LS-120/240 Superdisk, Clik! drives).

Mike Phillips <phillim2@comcast.net> [15 feb 2002]
        Token ring subsystem and drivers.

Anton Altaparmakov <aia21@cam.ac.uk> [15 feb 2002]
        I am the NTFS guy.

https://bugzilla.redhat.com/bugzilla [14 feb 2002]
        Reports of problems with the Red Hat shipped kernels.

Alan Cox <alan@lxorguk.ukuu.org.uk> [14 feb 2002]
        Linux 2.2 maintainer (maintenance fixes only).
        Collator of patches for unmaintained things in 2.2/2.4.
        Maintainer of the 2.4-ac (2.4 plus stuff being tested) tree.
        I2O, sound, 3c501 maintainer for 2.2/2.4.

ALSA development <alsa-devel@alsa-project.org> [12 feb 2002]
Jaroslav Kysela <perex@perex.cz> [12 feb 2002]
        Advanced Linux Sound Architecture
        ALSA patches are available at
        ftp://ftp.alsa-project.org/pub/kernel-patches/*

Neil Brown <neilb@cse.unsw.edu.au> [08 feb 2002]
        I am interested in any issues with the code in:
        NFS server    (fs/nfsd/*)
        software RAID (drivers/md/{md,raid,linear}*)
        or related include files.

Maksim Krasnyanskiy <maxk@qualcomm.com> [08 feb 2002]
        I'm author and maintainer of the Bluetooth subsystem
        and Universal TUN/TAP device driver.
        These days mostly working on Bluetooth stuff.

Rik van Riel <riel@conectiva.com.br> [07 feb 2002]
        Send me VM related stuff, please CC to linux-mm@kvack.org

Geert Uytterhoeven <geert@linux-m68k.org> [07 feb 2002]
        I work on the frame buffer subsystem, the m68k port (Amiga part),
        and the PPC port (CHRP LongTrail part).
        Unfortunately I barely have spare time to really work on these
        things. My job is not Linux-related (so far :-). I can not
        promise anything about my maintainership performance.

H. Peter Anvin <hpa@zytor.com> [07 feb 2002]
        i386 boot and feature code, i386 boot protocol, autofs3,
        compressed iso9660 (but I'll accept all iso9660-related
        changes).  kernel.org site manager; please contact me
        for sponsorship-related issues.

kernel.org admins <ftpadmin@kernel.org> [07 feb 2002]
        Kernel.org sysadmins.  Contact us if you notice something breaks,
        or if you want a change make sure you give us at least 1-2 weeks.
        Please note that we got a lot of feature requests, a lot of
        which conflict or simply aren't practical; we don't have time to
        respond to all requests.

Greg KH <greg@kroah.com> [07 feb 2002]
        I am USB and PCI Hotplug maintainer.

Trond Myklebust <trond.myklebust@fys.uio.no> [07 feb 2002]
        I am NFS client maintainer.

James Simmons <jsimmons@transvirtual.com> [07 feb 2002]
        Console and framebuffer sybsustems.
        I also play around with the input layer.

Richard Gooch <rgooch@atnf.csiro.au> [07 feb 2002]
        I maintain devfs. I want people to Cc: me when reporting devfs
        problems, since I don't read all messages on linux-kernel.
        Send devfs related patches to me directly, rather than
        bypassing me and sending to Linus/Marcelo/Alan/Dave etc.

Russell King <rmk@arm.linux.org.uk> [06 feb 2002]
        ARM architecture maintainer.  Please send all ARM patches through
        the patch system at http://www.arm.linux.org.uk/developer/patches/
        New serial drivers maintainer for 2.5.  Submit patches to
        rmk+serial@arm.linux.org.uk

Andrew Morton <akpm@zip.com.au> [05 feb 2002]
        I'm receptive to any reproducible bug anywhere in the 2.4 kernel.
        Specialising in ext2, ext3 and network drivers.
        Not thinking about 2.5.x at this time.

Petr Vandrovec <vandrove@vc.cvut.cz> [05 feb 2002]
        ncpfs filesystem, matrox framebuffer driver, problems related
        to VMware - in all of 2.2.x, 2.4.x and 2.5.x.

Reiserfs developers list <reiserfs-dev@namesys.com> [05 feb 2002]
        Send all reiserfs-related stuff here including but not limited to bug
        reports, fixes, suggestions.

Oleg Drokin <green@linuxhacker.ru> [05 feb 2002]
        SA11x0 USB-ethernet and SA11x0 watchdog are mine.

======= These entries are suggested by lkml folks ========

Ralf Baechle <ralf@gnu.org> [27 mar 2002]
        I am mips/mips64 maintainer.

David S. Miller <davem@redhat.com> [07 feb 2002]
        I am Sparc64 and networking core maintainer.

======= These ones I made myself ========
======= I am waiting confirmation/correction from these people ========

Urban Widmark <urban@teststation.com> [13 feb 2002]
        smbfs

video4linux list <video4linux-list@redhat.com> [12 feb 2002]
Gerd Knorr <kraxel@bytesex.org> [12 feb 2002]
        video4linux

Tim Waugh <twaugh@redhat.com> [08 feb 2002]
        > Who is maintaining the linux iomega stuff?
        For 2.4.x, me (in theory). I don't have time for 2.5.x at the moment.

Alexander Viro <viro@math.psu.edu> [5 feb 2002]
        I am NOT a fs subsystem maintainer. But I won't kill
        you if you send me some generic fs bug reports and (hopefully) patches.

Eric S. Raymond <esr@thyrsus.com> [5 feb 2002]
        Send kernel configuration bug reports and suggestions to me.
        Also I'll be more than happy to accept help enties for kernel config
        options (Configure.help).

G?rard Roudier <groudier@free.fr> [5 feb 2002]
        I am SCSI guy.

Jens Axboe <axboe@suse.de> [5 feb 2002]
        I am block device subsystem maintainer.

Linus Torvalds <torvalds@transmeta.com> [5 feb 2002]
        Do not send anything to me unless it is for 2.5, well tested,
        discussed on lkml and is used by significant number of people.
        In general it is a bad idea to send me small fixes and driver
        updates, send them to subsystem maintainers and/or
        "small stuff" integrator (currently Dave Jones <davej@suse.de>,
        see his entry). Sorry, I can't do everything.

Marcelo Tosatti <marcelo@conectiva.com.br> [5 feb 2002]
        Do not send anything to me unless it is for 2.4 and well tested.
        If you are sending me small fixes and driver updates, send
        a copy to subsystem maintainers and/or "small stuff" integrators:
        - Alan Cox <alan@lxorguk.ukuu.org.uk>,
        - Rusty Russell <trivial@rustcorp.com.au>.

Rusty Russell <rusty@rustcorp.com.au> [5 feb 2002]
        > Here are some cleanups of whitespace in .....
        Want me to add this to the trivial patch collection for tracking?
        If so just send (or cc:) it to trivial@rustcorp.com.au.

The following patch seems to fix building IDE as a module in 2.5.41. I am running this code on the machine that I'm using to compose this email.

A couple of notes:

1. For the time being, I have reassembled some of the drivers/ide object files into ide-mod.o again, because there are some circular references (not necessarily a bad thing) that modprobe cannot otherwise handle. For now, this includes putting ide-probe in ide-mod.
2. I have changed cmd640.o and legacy.o from dep_bool to dep_tristate and made them also depend on $CONFIG_BLK_DEV_IDE, so that they will only be offered as modules if ide-mod.o is a module (since, like any IDE driver, they require some symbols in ide-mod.o).

These changes are probably not perfect, but I think they should be an improvement with no real disadvantages in comparison to what they replace, so I would encourage you to integrate the changes if you see no problem. Please let me know what you want to do, or if there is something more you'd like me to do regarding this patch.

On behalf of the EVMS team, I would like to submit the Enterprise Volume Management System for review and possible inclusion in the 2.5 kernel.

This submission includes only the core driver and include files. Additional plugins will be submitted in the future in separate patches.

This series of patches contains the following files:

1. evms.c
2. services.c
3. discover.c
4. passthru.c
5. evms_core.h
6. evms.h
7. evms_ioctl.h
8. evms_biosplit.h
9. miscellaneous files

If you are interested in other information about EVMS, or would like to obtain the user-space administration tools, please visit our website at http://evms.sourceforge.net/.

Thank you very much for taking the time to review this submission. If you have any questions or comments, please email us at any time. We will be happy to do whatever is necessary to make EVMS acceptable for inclusion in the 2.5 tree.

It is time for you to step up to the plate!

As many people know, Bartlomiej is someone whom I trust with the driver without reservations. Since I am off working on several other issues, I would request the Maintainership be dual duty split over all kernel versions regardless. I am hoping Bartlomiej will accept the shared task and everyone will accept his input without question, this includes me too.

I will still be around and active; however, the task is so large now it truly does require a team. Please sign up to help Bart.

I am developing the Linux kernel support required to support Advanced TCA (PICMG 3.0) architecture. Advanced TCA is a technology where boards exist in a chassis and can either be processor nodes or storage nodes. All blades in the chassis are connected by FibreChannel and Ethernet. The blades can be hot added or hot removed while the Linux processor nodes are active, meaning that the SCSI subsystem must add devices on insertion requests and remove devices on ejection requests.

The following is the first public patch that I am posting that adds support for SCSI and FibreChannel hotswap via a programmatic kernel interface, as well as userland access via ioctls.

The second patch is a FibreChannel driver that is modified to support SCSI hotswap.

This mechanism is far superior to /proc/scsi/scsi because it:

1. provides true FibreChannel hotswap support (at this point qlogic FC HBAs)
2. is programmatic such that errors can be reported from kernel to user without looking is /var/log/.
3. Provides superior response times vs opening a file and writing to proc.
4. Easier to control from kernel and user via C APIs vs using open/write.

http://www.sourceforge.net/project/showfiles.php?group_id=64580

I am announcing a sourceforge project for developing support in Linux kernel for Advanced TCA (PICMG 3.0) architecture. Advanced TCA is a technology where boards exist in a chassis and can either be processor nodes or storage nodes. All boards in the chassis are connected by FibreChannel and Ethernet. The blades can be hot added or hot removed while the Linux processor nodes are active, meaning, that the SCSI subsystem must add devices on insertion request and remove devices on ejection requests. Further the typical /dev/sda naming of devices is not appropriate since device nodes can change depending on the insertion order of disks.

These patches are for Linux 2.4.19 and work with the Qlogic 2300 FibreChannel driver and at this point mostly support hotswap of the disk subsystem.

The patches consist of a SCSI hotswap patch for 2.4 kernel and QLA 2300 support.

The patches also consist of a GA Mapper library which maps fibrechannel WWNs to devices in devfs filesystems such as /dev/scsi/chassis/slot/disc.

The sourceforge project also contains a userland library for each patch and userland applications such that these operations can be scripted.

Advanced TCA uses IPMI, so this project will use the IPMI driver being developed by Corey Minyard.

To be posted are userland or kernel hotswap managers. I've not decided how to do this yet, so I'll post the bits when they are done.

At http://www.xs4all.nl/~zippel/lc/ you can find as usual the latest version of the new config system. I still haven't got a single mail from someone who tried it and didn't like it, what makes me a bit nervous :), so if you think something must be wrong, now is your last chance. Next version will go to Linus. Changes:

• as alternative suggestion for the config name I used "Kconfig" this time. I tried "Config", but somehow that's terrible to do find for, as one gets to many false positives. Even with a capital 'C' there are still these:
  Documentation/networking/Configurable
  scripts/Configure
  (ok, the latter will go away :) ).
• kbuild fixes (many thanks to Sam Ravnborg), I only added the clean targets.
• the back end is now generated as shared library and loaded by qconf at run time.
• small syntax change: "depends on", "requires" is also accepted besides "depends", generated is "depends on".
• conf displays the help text again.
• the behaviour difference in qconf between qt2 and qt3, when all symbols are shown, is fixed.

UML has been updated to 2.5.42 and UML 2.4.19-12. In non-numeric terms, this means the following:

• the usual build fixes to keep up with kbuild
• the SMP work from UML 2.4.19-12 - it seems reasonably functional and stable, but there are some unexplained crashes still. Also, the fixes from UML 2.4.19-13 aren't in yet, so an SMP UML will leave children around after exiting (the idle threads for processors 1 ... ncpus - 1). These children will interfere with rebooting, and will also hold down host memory.
• various cleanups and bug fixes

The patch is available at
http://uml-pub.ists.dartmouth.edu/uml/uml-patch-2.5.42-1.bz2

For the other UML mirrors and other downloads, see
http://user-mode-linux.sourceforge.net/dl-sf.html

Other links of interest:

The UML project home page : http://user-mode-linux.sourceforge.net
The UML Community site : http://usermodelinux.org

Enclosed please find patches to add extended attribute support to the ext2 and ext3 filesystems. It is a port of Andreas Gruenbacher's patches, which have been quite well tested at this point. Full support for extended attributes have been in e2fsprogs for quite some time. In addition, if CONFIG_EXT[23]_FS_ATTR is not enabled, the code path changes are quite minimal, and hence this should be a very low-risk patch. Please apply.

These patches are a prerequisite for the port of Andreas Gruenbacher's ACL patches, which will follow shortly.

This first patch creates a generic interface for registering caches with the VM subsystem so that they can react appropriately to memory pressure.

Actually, I did, for those comments that made sense. The fs/Config.in logic has been cleaned up, as well as removing excess header files, stray LINUX_VERSION_CODE #ifdef's that I had missed the first time around, etc.

fs/mbcache.c is still there because it applies to both ext2 and ext3 filesystems, and so your suggestion of moving it into the ext2 and ext3 directories would cause code duplication and maintenance headaches. It also *can* be used by other filesystems, as it is written in a generic way. The fs/Config.in only compiles it in if necessary (i.e., if ext2/3 extended attribute is enabled) so it won't cause code bloat for other filesystems if it is not needed.

The superblock fields are more of an issue with the posix acl changes than for the extended attribute patches. I had wanted to get the extended attribute changes in first, since they stand alone, and so I have fewer patches to juggle.

Due to popular request[1], Trivial Patch Monkey acquires its own web page:

http://www.<CC>.kernel.org/pub/linux/kernel/people/rusty/trivial

Those aren't modem ports; those are POTS ports for HomePNA (http://homepna.org/) networking.

It will work fine using the RJ45 connector; chances are the PhoneNet networking will work fine if you just *try* it.

An updated uClinux patch is available at:

http://www.uclinux.org/pub/uClinux/uClinux-2.5.x/linux-2.5.42uc1.patch.gz

Changelog:

1. v850 update
2. cleaned up mm/page_alloc.c

Smaller specific patches:

• FEC ColdFire 5272 ethernet driver
  http://www.uclinux.org/pub/uClinux/uClinux-2.5.x/linux-2.5.42uc1-fec.patch.gz
• m68k/ColdFire/v850 serial drivers
  http://www.uclinux.org/pub/uClinux/uClinux-2.5.x/linux-2.5.42uc1-serial.patch.gz
• 68328 frame buffer
  http://www.uclinux.org/pub/uClinux/uClinux-2.5.x/linux-2.5.42uc1-fb.patch.gz
• binfmt_flat loader
  http://www.uclinux.org/pub/uClinux/uClinux-2.5.x/linux-2.5.42uc1-binflat.patch.gz
• m68knommu architecture
  http://www.uclinux.org/pub/uClinux/uClinux-2.5.x/linux-2.5.42uc1-m68knommu.patch.gz
• v850 architecture
  http://www.uclinux.org/pub/uClinux/uClinux-2.5.x/linux-2.5.42uc1-v850.patch.gz
• mm (MMU-less) only patch
  http://www.uclinux.org/pub/uClinux/uClinux-2.5.x/linux-2.5.42uc1-mm.patch.gz

This, patch implements the POSIX clocks and timers functions. The two standard clocks are defined(CLOCK_REALTIME & CLOCK_MONOTONIC).

With this version, nano_sleep() is rolled into clock_nanosleep(). Also a bug fix in clock_nanosleep().

kernel/timer.c is modified to remove the timer_t typedef which conflicts with the POSIX standard definition for this type.

The patch introduces a new kernel source (posix-timers.c) which contains most of the code.

This implementation defines a timer as a system wide resource with system wide limits on the number of allocated timers. This number can be set at configure time and is defaulted to 3000. There are NO other limits on how many timers a process can have.

Kernel version 2.5.42-bk2

Test programs, man pages and readme files are available on the sourceforge high-res-timers site:

http://sourceforge.net/projects/high-res-timers/

Hi, all. Version 199.17 of my devfs patch is now available from:
http://www.atnf.csiro.au/~rgooch/linux/kernel-patches.html
The devfs FAQ is also available here.

Patch directly available from:
ftp://ftp.??.kernel.org/pub/linux/kernel/people/rgooch/v2.4/devfs-patch-current.gz

AND:
ftp://ftp.atnf.csiro.au/pub/people/rgooch/linux/kernel-patches/v2.4/devfs-patch-current.gz

This is against 2.4.20-pre11. Highlights of this release:

• Updated README from master HTML file
• Switched lingering structure field initialiser to ISO C
• Added locking when setting/clearing flags
• Documentation fix in fs/devfs/util.c
• Created <devfs_find_and_unregister>

Hi, all. Version 218 of my devfs patch is now available from:
http://www.atnf.csiro.au/~rgooch/linux/kernel-patches.html
The devfs FAQ is also available here.

Patch directly available from:
ftp://ftp.??.kernel.org/pub/linux/kernel/people/rgooch/v2.5/devfs-patch-current.gz

AND:
ftp://ftp.atnf.csiro.au/pub/people/rgooch/linux/kernel-patches/v2.5/devfs-patch-current.gz

NOTE: kernel 2.5.1 and later require devfsd-v1.3.19 or later.

This is against 2.5.43. Highlights of this release:

• Removed DEVFS_FL_AUTO_OWNER flag
• Switched lingering structure field initialiser to ISO C
• Added locking when setting/clearing flags
• Documentation fix in fs/devfs/util.c

url: http://www.zip.com.au/~akpm/linux/patches/2.5/2.5.43/2.5.43-mm1/

• The faster copy_*_user patch for Intel ia32 CPUs has been updated to be a little faster.
• A few 2.5.43 compilation fixes are included.
• Ingo's get_unmapped_area() speedup is added
• Included the extended attributes and posix ACL code. This feature is late, IMO. People who want this would be advised to help shake it down.
• There are still a few problems with the shared pagetable code. One of David's fixup patches didn't work out, so there are two followup patches over in the experimental/ directory. They're for David - don't use them.

• There's a little tweak here (no-reclaim-throttle.patch) which will improve interactivity on small machines during heavy writeout.

  But generally, for those people who have had problems with sluggishness and swappiness in the 2.5 VM: 2.5.43 pretty much has it all. Please give it a shot.

  /proc/sys/vm/swappiness is available for playing with. Default value is 60%, and 100 gives you the previous 2.5 behaviour.

  Some things are slower - most notably things which involve simultaneous reading from and writing to the same disk. Such workloads were traded off against latency under write loads. I expect that with careful attention some of this can be pulled back, but it's not a large regression. Maybe up to 10-20%.

This patch contains updates to 2.5.43 and syncs the 2.5 UML up with my 2.4 tree.

The 2.5.43 updates are build fixes, and updated defconfig, and an entry for lookup_dcookie.

The other stuff includes

not calling request_irq from an interrupt handler
fix a hang caused by xterm not running successfully
exporting rwlock symbols
killing off all the idle threads on halt
other small updates, fixes, and cleanups

ftp://oss.sgi.com/projects/kdb/download/v2.3/

kdb-v2.3-2.5.43-common-1.bz2
kdb-v2.3-2.5.43-i386-1.bz2

The usb keyboard patch has been merged from kdb v2.3-2.4.19-{common,i386}. It does not compile on 2.5.43, the APIs have changed. If you can help with usb polling support for kdb, grep for CONFIG_KDB_USB. Without community support, the usb support will be dropped.

Changelog extracts.

2.5.43-common-1

2002-10-17 Keith Owens <kaos@sgi.com>

* Upgrade to 2.5.43.
* kdb v2.3-2.5.43-common-1.

2.5.43-i386-1

2002-10-17 Keith Owens <kaos@sgi.com>

* Upgrade to 2.5.43.
* kdb v2.3-2.5.43-i386-1.

No kdb patch for ia64 until there is a more recent ia64 kernel patch for 2.5.

v2.3/README

Starting with kdb v2.0 there is a common patch against each kernel which contains all the architecture independent code plus separate architecture dependent patches. Apply the common patch for your kernel plus at least one architecture dependent patch, the architecture patches activate kdb.

The naming convention for kdb patches is :-

• vx.y The version of kdb. x.y is updated as new features are added to kdb.
• -v.p.s The kernel version that the patch applies to. 's' may include -pre, -rc or whatever numbering system the kernel keepers have thought up this week.
• -common The common kdb code. Everybody needs this.
• -i386 Architecture dependent code for i386.
• -ia64 Architecture dependent code for ia64, etc.
• -n If there are multiple kdb patches against the same kernel version then the last number is incremented.

To build kdb for your kernel, apply the common kdb patch which is less than or equal to the kernel v.p.s, taking the highest value of '-n' if there is more than one. Apply the relevant arch dependent patch with the same value of 'vx.y-v.p.s-', taking the highest value of '-n' if there is more than one.

For example, to use kdb for i386 on kernel 2.5.43, apply
kdb-v2.3-2.5.43-common-<n> (use highest value of <n>)
kdb-v2.3-2.5.43-i386-<n> (use highest value of <n>)
in that order.

Use patch -p1 for all patches.

url: http://www.zip.com.au/~akpm/linux/patches/2.5/2.5.43/2.5.43-mm2/

• I've pretty much dropped the per-cpu pages patches which Martin and I developed.

  These patches gave a 1-2% benefit in kernel compiles, up to 4% in Randy Hron's testing of the autoconf build tests. 2.2% in specweb. And a 60% speedup in a little app which just looped writing 80k to a file and truncating it off again.

  All the above came from the cache-warmth effect. The patches would give an overall 15% speedup due to reduced lock contention in Anton's testing on the big PPC64 machines, but he fixed that anyway by getting NUMA working properly.

  In my opinion, all the above is just too thin to justify throwing a bunch of new stuff into the page allocator.

  I shall continue to distribute these patches. Maybe someone will find them sufficiently beneficial for something at a future time.

  But it simply seems to be the case that no interesting workloads repeatedly allocate and free small numbers of pages (in the 10-50 range).

• The shared pagetable code is not in the main diff - it has a few problems at present. The patches are over in the experimental/ directory. order of application is:

  shpte.patch
  shpte-lock-ranking-fix.patch
  shmmap.patch
  handle-mm-fault-locking.patch
  mremap-shared-pagetable-fix.patch
  shpte-unmap_all_pages_fix.patch
  unmap_page_range-fix.patch

• The slab rework is stable now and Manfred has some good microbenchmark numbers from that. But we're still not quite ready with that code because the hotplug CPU APIs have, shall we say, a few shortcomings.

Here's the monster flame-war we had the last time this issue was debated
http://www.uwsg.iu.edu/hypermail/linux/kernel/0109.3/0102.html

My argument against the intent of this change is that no, I do not think we should restrict LSM modules to be GPL-only. LSM is an API for loading externally developed packages of software, similar to syscalls. There is benefit in permitting proprietary modules (you get additional modules that you would not get otherwise) just as there is benefit in permitting proprietary applications (you get Oracle, DB2, and WordPerfect).

My argument against the implementation technique of dropping in these export GPLonly symbols is that my read of the GPL itself means that they have no legal impact. The crux of the matter is whether a *court* finds that LSM is "linking" (in the GPL sense) or is an "interface":

• If it is "linking": then all LSM modules end up GPL'd, regardless of what any of us want.
• If it is "an interface": then the GPL specifically *prohibits* you from imposing additional restrictions, such as requiring someone else's module to be GPL'd, to wit:
• Clause 4: "You may not copy, modify, sublicense, or distribute the Program except as expressly provided under this License."
• Clause 6: "... You may not impose any further restrictions on the recipients' exercise of the rights granted herein."

Therefore, the EXPORT_SYMBOL_GPL is just a bunch of useless bloat, with no legal standing what so ever. If kernel module interfaces are held by a court to be linking, then export symbols are redundant. If kernel module interfaces are held by a court to be an interface, then the export symbols are just wrong.

Note that if this fight ends up being a major issue, I'm just going to remove LSM and let the security vendors do their own thing. So far

• I have not seen a lot of actual usage of the hooks
• seen a number of people who still worry that the hooks degrade performance in critical areas
• the worry that people use it for non-GPL'd modules is apparently real, considering Crispin's reply.

I will re-iterate my stance on the GPL and kernel modules:

There is NOTHING in the kernel license that allows modules to be non-GPL'd.

The _only_ thing that allows for non-GPL modules is copyright law, and in particular the "derived work" issue. A vendor who distributes non-GPL modules is _not_ protected by the module interface per se, and should feel very confident that they can show in a court of law that the code is not derived.

The module interface has NEVER been documented or meant to be a GPL barrier. The COPYING clearly states that the system call layer is such a barrier, so if you do your work in user land you're not in any way beholden to the GPL. The module interfaces are not system calls: there are system calls used to _install_ them, but the actual interfaces are not.

The original binary-only modules were for things that were pre-existing works of code, ie drivers and filesystems ported from other operating systems, which thus could clearly be argued to not be derived works, and the original limited export table also acted somewhat as a barrier to show a level of distance.

In short, Crispin: I'm going to apply the patch, and if you as a copyright holder of that file disagree, I will simply remove all of he LSM code from the kernel. I think it's very clear that a LSM module is a derived work, and thus copyright law and the GPL are not in any way unclear about it.

If people think they can avoid the GPL by using function pointers, they are WRONG. And they have always been wrong.

Side note: it should be noted that legally the GPLONLY note is nothing but a strong hint and has nothing to do with the license (and only matters for the _enforcement_ of said license). The fact is:

• the kernel copyright requires the GPL for derived works anyway.

• if a company feels confident that they can prove in court that their module is not a derived work, the GPL doesn't matter _anyway_, since a copyright license at that point is meaningless and wouldn't cover the work regardless of whether we say it is GPLONLY or not.

  (In other words: for provably non-derived works, whatever kernel license we choose is totally irrelevant)

So the GPLONLY is really a big red warning flag: "Danger, Will Robinson".

It doesn't have any real legal effect on th emeaning of the license itself, except in the sense that it's another way to inform users about the copyright license (think of it as a "click through" issue - GPLONLY forces you to "click through" the fact that the kernel is under the GPL and thus derived works have to be too).

Clearly "click through" _has_ been considered a legally meaningful thing, in that it voids the argument that somebody wasn't aware of the license. It doesn't change what you can or cannot do, but it has some meaning for whether it could be wilful infringement or just honest mistake.

one more addition here: as long as those works do not copy any part of the kernel, be that source code or binary code. Ie. they:

• dont play fancy games binary-patching the kernel or something to that extent.

There's been a precedent created in the US just two days ago, at the appelate level, that makes certain types of functionality-enhancing 'binary-patching' practices fall under the copyright of the patched work.

Ie. the GPL qualifies even if the main body of the work in question is not derived from the kernel, but the work depends on modifying the kernel. So it's a questionable practice even for non-derived bin-only modules to patch the kernel or modify it in any not originally intended way.

and the well-known issues of:

• dont use inline functions in headers
• probably even the structure definitions in headers qualify

both can be independently created via the rules of reverse engineering. (whatever they are in the country it's done - but be prepared for the US to attempt to take jurisdiction over your acts, wherever you are ...)

Thanks for the clarification, but that still leaves questions. In particular, it is unclear whether a work is "derived" if it includes kernel header files, which is more or less required if you hope to make a module fit the interface.

Note that if we decide that #include of a kernel header file means that a work is derived, then we cause another problem: most Linux applications come under the GPL. glibc #includes some kernel header files, and most Linux applications #include glibc headers, so most applications are #including kernel header files. If #include is the basis for declaring a module to be a derived work of the kernel, then there is some bad news coming for people who like to use Oracle and DB2 on Linux ...

Here is now the final release (it's as usual at http://www.xs4all.nl/~zippel/lc/ ). Changes in this release:

• help texts are a bit more indented (by two spaces) and long texts (more than 10 lines), start with "---help---".
• in preparation of the library API I renamed a few structures/symbols.

Linus, nobody complained about it, so I put it now into your hands. :) The easiest way is probably to use the converter with 'make install KERNELSRC=...', which will convert your current tree.

The generated name is still Kconfig, if you prefer something different, it's easily changable. The name is generated in cml1.y:gen_filename() and only a search&replace in fixup-all.diff is needed.