Merges with all the regular suspects - Al's partitioning, Andrew on VM, USB, networking, sparc, net drivers. And Ingo has been working on fixing up the inevitable details in the thread signal stuff, as well as updating the smp-scalable timer code.

And ISDN, kbuild, ARM, uml...

And a small reminder that we're now officially in the last month of features, and since I'm going to be away basically the last week of October, so I actually personally consider Oct 20th to be the drop-date, unless you've got a really good and scary costume.. So don't try to leave it to the last day.

[ And if that didn't worry you, the following should: I'm perfectly happy with the kernel, and as such whatever features _you_ think are missing might just not weigh too much with me if you then also make the mistake of trying to leave them for the last crunch. I might just take the last day off too ;]

And if it wasn't clear to the non-2.5-development people out there, yes you _should_ also test this code out even before the freeze. The IDE layer shouldn't be all that scary any more, and while there are still silly things like trivially non-compiling setups etc, it's generally a good idea to try things out as widely as possible before it's getting too late to complain about things..

Personal opinion (and only that): not much chance for a filesystem trashing.

There's more chance of something just not _working_ than of disk corruption. Ie you may find that some driver you need doesn't compile because it hasn't been updated to the new world order yet, for example.

And people still report problems booting, for example, whatever the reason. So make sure you have a working choice in your lilo configuration or whatever.

But from what we've seen lately, there really aren't reports of corrupted disks or anything like that that I've seen. Which is obviously not to say that it couldn't happen, but it's not a very likely occurrence.

That said, I can't set other peoples risk bars for them.

Pease don't introduce more typedefs. They only hide what the hell the thing is, which is actively _bad_ for structures, since passing a structure by value etc is something that should never be done, for example.

The few saved characters of typing do not actually _buy_ you anything else, and only obscures what the thing is.

Also, it's against the Linux coding standard, which does not like adding magic single-letter suffixes to things - that also is the case for your strange "_s" suffix for a structure (the real suffix is "_struct").

Remember: typing out something is not bad. It's _especially_ not bad if the typing makes it more clear what the thing is.

Btw, just to avoid counter-examples: Linux does use structures and typedefs occasionally to hide and force compiler typechecking on small structures on purpose. We have a few places where we do things like

        typedef struct {
                unsigned int value;
        } atomic_t;

(and similar things for the page table entries etc).

This is done because the things are often really regular scalars, but we use the structure as a strict type checking mechanism. In this case, using a typedef is fine, because we don't actually ever want to _access_ it as a structure, and the typedef provices exactly the kind of information hiding that we need.

But type hiding for a real structure just doesn't make sense, since we use it as a true structure, and hiding information just makes it harder to see.

Big things should have big names. That's why "u8" is u8, because it's not just physically small, it also has very little semantics associated with it.

I want those variable declarations to stand out, and make people understand that this is not just a variable, it's a structure, and it may be taking up a noticeable amount of space on the stack, for example.

That's the main issue for me. I don't personally care so much about trying to avoid dependencies in the header files that can also be problematic. That's probably partly because I use fast enough machines that parsing them a few extra times doesn't much bother me, and circular requirements tend to be rare enough not to bother me unduly.

So the thing is a big red warning sign that you're now using a complex data structure, and you should be aware of the semantics that go with it.

Attached is a patch which provides a rudimentary NUMA scheduler. This patch basically does two things:

• at exec() it finds the least loaded CPU to assign a task to;
• at load_balance() (find_busiest_queue() actually) it favors cpus on the same node for taking tasks from.

This has been tested on the IA32 based NUMAQ platform and shows performance gains for kernbench. Various microbenchmarks also show improvements and stickiness of processes to nodes. Profiles show that the kernbench performance improvements are directly attributable to the use of local memory caused by tasks running on the same node through their lifetime.

I will be doing much more testing of this, and likely will be tweaking some of the algorithms based upon test results. Any comments, suggestions, flames are welcome.

Patch applies to 2.5.40 and makes use of the new NUMA topology API. This scheduler change should work on other NUMA platforms with just the definition of the architecture specific macros in topology.h.

it's a start. But I'm afraid a full solution will need much more code (which is one of the problems with my NUMA scheduler patch).

The ideas behind your patch are:
1. Do initial load balancing, choose the least loaded CPU at the beginning of exec().
2. Favor own node for stealing if any CPU on the own node is >25% more loaded. Otherwise steal from another CPU if that one is >100% more loaded.

1. is fine but should ideally aim for equal load among nodes. In the current form I believe that the original load balancer does the job right after fork() (which must have happened before exec()). As you changed the original load balancer, you really need this initial balancing.

2. is ok as it makes it harder to change the node. But again, you don't aim at equally balanced nodes. And: if the task gets away from the node on which it got its memory, it has no reason to ever come back to it.

For a final solution I believe that we will need targets like:
(a) equally balance nodes
(b) return tasks to the nodes where their memory is
(c) make nodes "sticky" for tasks which have their memory on them, "repulsive" for other tasks.
But for a first attempt to get the scheduler more NUMA aware all this might be just too much.

With simple benchmarks you will most probably beat the plain O(1) scheduler on NUMA if you implement (a) in just 1. and 2. as your node is already somewhat "sticky". In complicated benchmarks (like a kernel compile ;-) it could already be too difficult to understand when the load balancer did what and why...

It would be nice to see some numbers.

this is just my opinion of how to use BitKeeper, not the "rule":

You can use BitKeeper for kernel development in two ways:

• as a tree to work out of, accepting changes and doing incremental things all along the way, including merging with the main releases.
• or as a way to send changes to a maintainer.

I think this is a pretty good point, and is something that I don't think anybody has ever really said explicitly before.

Some of the BK usage documentation (or "hints") by Jeff clearly imply this behaviour, but it's not really stated explicitly anywhere.

Also note that using multiple trees is pretty easy - you _can_ easily do development in the "export" tree, if you just make sure that you only do one kind of development. And then you have a separate "test" tree that is a "throw-away combination tree" which just pulls all the other trees and has the combination of all the different work trees.

That multi-tree approach has advantages quite outside of merging cleanly: it means that when trouble happens, and something doesn't work, it's really easy to test out other changes.

I personally often use the multi-tree approach myself when merging bigger changes (especially if there are other changes that are in the same area): before I apply something big, I clone my regular tree (often down to a known version, like the last release), and apply those changes in that separate tree.

Then I build and test that separate tree before I merge it into my "final merge" tree - it makes it easier to see whether problems are due to a specific line of patches, or whether it might be some interaction between different changes.

One reason it's so easy to merge with the USB people (and with Jeff and David and a number of others too, for that matter) is exactly the fact that when I get an email that says "pull this tree to get these USB changes", that is all I get. Not "random support changes to other parts of the kernel that I also used on my tree".

If I don't get a clean BK tree to pull from, I just cannot pull it. I end up applying the diffs by hand instead, at which point when I push out my end result, the original source of the patches does _not_ get a clean BK tree that matches mine, but instead gets a BK tree that has the changes TWICE, in addition to all the crud it already had.

Which now makes it doubly hard to see which parts I applied, and which ones I didn't - BK will usually have successfully merged the trees, but you don't actually get any real "source control". You only get a messy tree.

As a result, such a tree is even _less_ useful than it was last time, and definitely will never be pulled by me ever again, and the poor kernel developer ends up not getting any of the real advantages of BK at all.

In fact, _most_ people that merge with me using BK seem to use more than one tree already (some developers are very specialized and only have the one tree: JFS and ARM come to mind).

I think it's very much a "getting used to the experience". Some people don't like it, and that's fine - I have absolutely no problem applying clean patches either, and some of the major kernel developers have never used a BK tree to merge with me (Andrew, Viro, Alan, Ingo..) and it hasn't been a problem.

I personally think there is a very simple rule to using BK: if you're doing development, and you only have one tree, you're doing something wrong. The "single tree" approach is fine if your use of BK is really more of a "anonymous CVS" replacement - you use BK only to track somebody elses tree and build that. But if you do real development, you should have multiple trees, or you're not really using BK as a SCM.

it is already supported on both. it works as an emu10k1 (SB Live) compatible, i.e. no new feature such like 24bit support.

both drivers have advantage and disadvantage. OSS driver has much better DSP manager, while ALSA driver supports WaveTable MIDI.

NO! Dammit, you'll break everyone who is using these compact names to mount the root FS. Look more closely at the code you're trying to remove, and you'll see it's *not* used to avoid work in startup scripts. It's only used to create the devfs entry for the root FS.

This change is gratuitous. The code is __init code anyway, so doesn't contribute to bloat. And forcing people to migrate to the longer names isn't reasonable, as it chews up precious space on the kernel command line. I've had times where I ran out of space when I had too many options.

Linus, please don't apply.

The convenience names for the root FS *have* been in the kernel since before 2.4.x. I agree with the initramfs approach: that's been my plan for handling the rootFS compatibility names (put a mini devfsd into initramfs). But until all the infrastructure for that is ready, you can't just go around breaking features people rely on. Especially where there is no benefit to breaking it.

If you really feel strongly about it, and don't want to wait for devfsd to be added to initramfs, by all means move the current code (or the moral equivalent) to initramfs. But you'll have to wait for initramfs to be available and for it to be the default.

Now that the Linux kernel is once again able to run all the tests we have and since glibc 2.3 was released it was time for a new code drop. I've uploaded the second code drop for the Native POSIX Thread Library:

ftp://people.redhat.com/drepper/nptl/nptl-0.2.tar.bz2

You need

• the latest of Linus' kernel from BitKeeper (or 2.5.41 when it is released);
• glibc 2.3
• the very latest in tools such as
• gcc either from the current development branch or the gcc 3.2 from Red Hat Linux 8;
• binutils preferrably from CVS, from H.J. Lu's latest release for Linux, or from RHL 8.

Compiling glibc should proceed smoothly. But there are a number of tests which fail, mostly because some functionality is missing in glibc. Ignore those errors. It is only important that all tests in nptl/ are passing. Run

make subdirs=nptl check

to run all thread tests.

This version features several improvements:

• all APIs are now implemented;
• fork handling has been improved; stacks in the child are freed; atfork handlers are removed if they were registered from a module which gets unloaded.
• pthread_tryjoin_np and pthread_timedjoin_np are implemented
• TSD handling corrected and optimized.
• many more tests which also test the underlying kernel implementation.
• the build infrastructure has been implemented so that the DSO and archives are built in usable form and with correct named.
• libthread_db has been implemented. This is the library which is needed by all program which need to get access to internals of libpthread (mainly debuggers).
• the CPU clock functions are implemented

The white paper hasn't yet been updated. It's still available at

http://people.redhat.com/drepper/nptl-design.pdf

This release should be ready for some serious testing. I know it is hard to compile which I why I'm looking into providing binary RPMs. They can be used on non-critical systems. I'll only be able to provide binaries for RHL8 based systems, though, and the kernel still must be installed separately.

The next steps will include:

• write more tests and fix the bugs which are discovered this way
• update the white paper
• write and run more performance tests
• port to IA-64

Interested parties are once again invited to join the mailing we created:

phil-list@redhat.com

Go to

https://listman.redhat.com/mailman/listinfo/phil-list

to subscribe, unsubscribe, or review the archive.

too many to list, really. It's more than 60 separate patches that went into 2.5 in the past 2 months that implement all the necessery infrastructure for NPTL-style 1:1 threading. Futexes had to be fixed too, so it's not like you could use the existing 2.4 futex patch for NPTL. I'll attempt a 2.4 backport of all the threading bits within the next couple of weeks, but it's not a matter of a couple of hours ...

but, 2.5 isnt all that bad these days, and Arjan is currently working on 2.5 kernel rpms, to make it even easier to try out. (it will be announced to phil-list once he's done.)

These are the patches (9 in all) for the Linux Kernel Crash Dump modifications for 2.5. This allows crash dumps to be built as a module in the kernel and also includes a breakdown of a few of the changes needed in the kernel. The current version will allow for block dumping, and has the ability to readily integrate network dumping (a la Red Hat).

The big debatable issue I can see right away is the dump_in_progress addition to schedule(), which can certainly be moved out or modified to appease people wanting a tight scheduler loop.

Please accept these patches or provide feedback on how we can modify them for acceptance.

Who do you want to accept these patches? If it's Linus, you should send them to him.

Documentation/SubmittingPatches doesn't say so, but lately it's become quite common and desirable to use diffstat output above patches to summarize the files modified and how much they are modified.

here's a merge of my SCx200 patches with Linux-2.4 from the bitkeeper tree. I'm waiting for Linus to apply the 2.5 patch before submitting this to Marcelo again, but I wanted to post this anyway. Please comment if there is anything strange with these patches.

The patch is also available as a bitkeeper with:

bk pull bk://zoo.weinigel.se/scx200-2.4

_please_ do this the regular way next time. There's even a script to help you do it in linux/Documentation/BK-usage/bk-mak-sum, which does it all for you for BK patches.

(many people end up doing their own thing, you don't have to use that particular script, of course. But the important thing I want is that the _email_ should contain enough information to make a good first pass judgement on what the patch does, and in particular it is important for me to see what a "bk pull" will actually change.)

That's why the "diffstat" is important to me if I do a BK pull - and why I want to see the patches as plaintext if I apply stuff to generic files..

So:

• if you use BK (which is great - your tree looked fine and the only real problem was that I had to verify it separately by hand first), please send one email for the "bk pull", and include a diffstat for the whole thing in that one email.
• if you use patches, please send them as clear-text in the email itself, and don't think that I want to go fetch them separately from some other site.

For optimal exposure, do both - this is what Greg KH does for USB stuff (he sends the BK email to me and to the kernel list, and sends individual patches to the kernel list only). Which really helps the people who don't want to use BK for some reason.

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

• Peter Chubb's 64-bit sector_t patches have been included. These are working fine and are a 2.6 must-have, IMO.
• Included Manfred's slab rework. No problems observed there.

• The per-cpu hot-n-cold pages code continues to disappoint. For some weird reason, the enormous lock contention which was observed in rmqueue and __free_pages_ok in 2.5.9 has vanished in 2.5.40 on the big ppc64 boxen. So these patches fix something which isn't there any more. Could be related to the hardware (which changed); we're still poking at it.

  One test which involves repeatedly writing and then truncating smallish files was sped up 60%, which indicates that the cache locality stuff is working correctly, but it's a bit artificial.

  Ingo said that his 2.4-based per-cpu-pages patch was beneficial to specweb, but nobody has tested these patches with specweb. Hint.

• Started work on /proc/sys/vm/swappiness. Setting it to 100% gives you current 2.5 behaviour. Setting it to 0 feels pretty similar to 2.4.19.

  I ran it for half a day; seems to work OK. Although running a KDE desktop on dual 25" monitors in 96 megabytes is not a ton of fun.

  More things to be done on this. If anyone tests this code on a small machine, you really do need to set /proc/sys/vm/dirty_async_ratio to 15. I'll be making this dynamic.

• Started work on a page reservation API to solve the problem of ENOMEM during radix-tree and pte_chain allocations. It's untested and unused at present.
• Dropped the sard patch for now - it kept on getting stomped by the gendisk rework.

In 2.5, it is unsafe to assume the current processor does not change out from under you - thus you must be atomic when calling smp_processor_id(). We introduced the get_cpu() and put_cpu() methods to provide a safe way to access the current processor.

This patch back-ports those interfaces to 2.4. Note they do nothing special: get_cpu() simply returns smp_processor_id() and put_cpu() is a no-op. But this will allow easier back-porting from 2.5 and common code-base for drivers, etc. It also does not hurt to be explicit that you do not want the processor to change.

As an example, I converted one use of smp_processor_id() to the new interface.

Patch is against 2.4.20-pre9, please apply.

The implementation of bcopy() in lib/string.c (and some other places such as the XFS header files) is incorrect as it implements bcopy as memcpy. This is wrong: bcopy should be the equivalent of memmove (which handles overlapping areas correctly).

I've dicussed it with a number of people, and the general consensus seems to be that it should be nuked entirely? Do you agree?

I agree. bcopy should just DIE. Some architectures may have historical trouble with gcc emitting bcopy for structure assignments (and that's definitely a memcpy with no overlap), but I think that's long gone (I know gcc on alpha used to do this several years ago).

XFS seems to be a big user of bcopy, though..

I will not apply a patch that removes bcopy() in the name of "cleanliness", if it then results in a number of modules just adding their own

#define bcopy(a,b,c) memcpy(b,a,c)

because then the whole cleanup would be pointless - it would just make some modules even uglier than they were before.

So I'd much rather see the XFS etc code moved away from bcopy() first, because that's the _real_ cleanup. The library code isn't all that ugly in comparison.

Could somebody drag the Irix team kicking and screaming into the 1980's, please?

I realize it might be quite painful for them, but maybe you could buy them a disco tape, so they'd feel a little bit more at home.

Linus "Stayin' alive, stayin' alive" Torvalds

How can it *not* be that simple?

No matter if you think bcopy should work for overlapping memory or not, there is a replacement standard function (by the 1989 ANSI C standard, so maybe the 1980's are not quite modern enough) that does exactly that, with nothing but rearranged parameters.

That's a purely mechanical change, on the same level as the kernel janitor stuff - hell, easier than the kernel janitor stuff.

I expect the reason it hasn't been done in Irix kernel code is simly that there was no real need to do it. I certainly do not imagine there's anything *hard* about it.

Hell, you could just use the #define method to map an XFS memcpy (or memmove) onto the Irix kernel library bcopy!

No, this is politics, not technical. (On both sides, of course.)

Linux Plug and Play Support V0.6

The included patch is essentially a Linux Plug and Play Support rewrite. It contains many significant improvements, including the following:

1. A Global Plug and Play Layer
• Now drivers do not have to worry about which plug and play protocol they are using. Calls are made directly to the Linux Plug and Play Layer and then forwarded to the appropriate protocol.
• This will make it very easy to integrate ACPI PnP support when it's ready
2. A complete Plug and Play BIOS driver
• The Plug and Play BIOS now supports reading and writing of resource configurations.
• It is now possible to enable disabled PNPBIOS devices. Therefore the user can safely enable PnP OS support in their BIOS.
3. Driver Model Integration
• The entire plug and play layer is integrated into the driver model
• The user interface is housed here
• PnP protocols are listed under the bus "pnp"
4. A powerful global resource configuration interface
• The user can use this to activate PnP devices for legacy and user-level drivers
• To enable a device the user can type the following to the desired driverfs listing:
  # echo "auto" > resources
• To manually set resources type the following:
  # echo "manual <depnum> <static/dynamic>" > resources
  <depnum> = configuration number
  <static> = for next boot
  <dynamic> = now
  ex:
  # echo "manual 1 dynamic" > resources
• To disable a device type the following:
  # echo "disable" > resources
5. Automatic resource allocation for needed devices
6. A PnP device name database

And many more improvements.

The code is relatively stable and I encourage anyone who's curious to try it out. Currently only the serial driver has been converted to the new APIs but that includes just about every modem. Patches to convert other drivers are welcome. Feel free to send bug reports, questions, comments, etc.

Oh, and I totally forgot ..

The merge from Andrew merged in various VM counter updates, which change /proc accounting in ways that make some of the system monitoring stuff unhappy. In particular, you'll find "vmstat" dumping core, and "top" has a few glitches too.

You can fix all of this by just upgrading to a newer "procps" package. Rik maintains a procps-2.0.9 (many of the stats were his) at

http://surriel.com/procps/

I don't think there are ready-made binary packages, but maybe some enterprising and helpful - and trustworthy - soul can do that and get vendors to add it to their upgrade list (or at least make it available in contrib).

It's the incredible mutable filesystem. As was talked about at the Kernel Summit in Ottawa, and as has been threatened in the past three months, here is the patch to rename driverfs to kfs.

It's really simple, and is basically a global search and replace of all the direct users of driverfs (so far only the driver model and acpi), as well as the documentation.

As a result of this, you must of course update your /etc/fstab to mount kfs instead of driverfs.

This is the first of four patches which add extended attribute support to the ext2 and ext3 filesystems. It is a port of Andreas Gruenbacher's patches, which have been well tested and in a number of distributions (including RH 8, if I'm not mistaken) already. I just ported it to 2.5 (these patches are versus 2.5.40). As always, since I touched the code last, any problems in it are my fault. :-)

These patches are prerequisite for the port of the Andreas Gruenbacher's ACL patches to 2.5, which I'm currently working on. But given the short time-frame before feature freeze, I'd like to get these out for review ASAP. Please comment and bleed on them.

The Linux Test Project test suite LTP-20021008.tgz has been released. Visit our website (http://ltp.sourceforge.net) to download the latest version of the testsuite, and for information on test results on pre-releases, release candidates & stable releases of the kernel. There is also a list of test cases that are expected to fail, please find the list at (http://ltp.sourceforge.net/expected-errors.php)

The highlights of this release are:

• Updated the STAX LTP driver. You can now specify client and server logging paths. The ability to define how long a single test is allowed run has been added. Plus, hardware information is now included in the logs for each client. The HowTo has been updated as well.
• Updated the Database Opensource Test Suite (DOTS) with added functionality to allow the use of MySQL and PostreSQL databases, complementing the existing features that allow the use of DB2, Oracle, and Sybase databases. Additionally, DOTS is now available as an on-demand test suite at the Open Source Development Lab's Linux Kernel Scalable Test Platform. (http://www.osdl.org/stp)
• An additional shared memory control test has been added (shmctl04), that tests the SHM_INFO command.

We encourage the community to post results, patches, or new tests on our mailing list, and to use the CVS bug tracking facility to report problems that you might encounter. More details available at our web-site.

I have put a new version of the IPMI driver on my home page (http://home.attbi.com/~minyard) that fixes a bug. A previous unannounce version is there (v3) that adds IPMB broadcast support and fixes a bug. If you are using this driver, you want to update to the newest version. These are only supplied as a patches against the previous version since the patches are small and apply to all kernel versions. If someone wants a full patch, I can do that, too.

I was toying with the idea of adding a socket interface to the IPMI driver. This way, it would naturally handle separation of addressing and data, and it wouldn't take up a character device. I think I could map everything the driver does into standard network calls, and the IPMB bus is sort of a network, anyway. Does anyone have any opinions on this?

PS - In case you don't know, IPMI is a standard for system management, it provides ways to detect the managed devices in the system and sensors attached to them. You can get more information at http://www.intel.com/design/servers/ipmi/spec.htm

My SCx200 patches just turned up in Linux-2.5.41, so I would like to submit them for 2.4 too so that 2.4 and 2.5 are synced.

The patch adds support for the National Semiconductor SCx200 processor family to Linux 2.4. The patch consists of the following drivers:

arch/i386/kernel/scx200.c -- give kernel access to the GPIO pins

drivers/chars/scx200_gpio.c -- give userspace access to the GPIO pins
drivers/chars/scx200_wdt.c -- watchdog timer driver

drivers/i2c/scx200_i2c.c -- use any two GPIO pins as an I2C bus
drivers/i2c/scx200_acb.c -- driver for the Access.BUS hardware

drivers/mtd/maps/scx200_docflash.c -- driver for a CFI flash connected to the DOCCS pin

If they look ok to you, please apply.

The latest set of MMU-less support patches are up. You can get the all-in-one patch at:

Change log:

1. patched against 2.5.41
2. reworked build system (support new kbuild changes)
3. switch to workqueue's in serial and ethernet drivers
4. started import Christop Hellwigs MM changes
• now CONFIG_MMU and CONFIG_SWAP defines
• more patches still to merge

You can get smaller patches here:

• FEC (5272) ethernet driver
  http://www.uclinux.org/pub/uClinux/uClinux-2.5.x/linux-2.5.41uc0-fec.patch.gz
• 68k/ColdFire/v850 serial drivers
  http://www.uclinux.org/pub/uClinux/uClinux-2.5.x/linux-2.5.41uc0-serial.patch.gz
• 68328 frame buffer driver
  http://www.uclinux.org/pub/uClinux/uClinux-2.5.x/linux-2.5.41uc0-fb.patch.gz
• FLAT file loader
  http://www.uclinux.org/pub/uClinux/uClinux-2.5.x/linux-2.5.41uc0-binflat.patch.gz
• m68knommu architecture support
  http://www.uclinux.org/pub/uClinux/uClinux-2.5.x/linux-2.5.41uc0-m68knommu.patch.gz
• v850 architecture support
  http://www.uclinux.org/pub/uClinux/uClinux-2.5.x/linux-2.5.41uc0-v850.patch.gz
• no VM memory support
  http://www.uclinux.org/pub/uClinux/uClinux-2.5.x/linux-2.5.41uc0-mmnommu.patch.gz

The following patch set adds ACL support to the ext2/3 filesystem. It is a port of the 0.8.50 patches from Andreas Gruenbacher. It requires the Extended Attribute patches which I had sent earlier as a pre-requisite, and represents the 2nd of 3 sets of patches from the acl.bestbits.at code. (The first set was the EA patches; this is the second set of patches; and the third set of patches adds ACL support to NFS, so that the NFS server respects the ACL set on the filesystem.)

Some of these patches in this set are shared in common with the XFS filesystem, and are needed for ACL support in XFS as well. These patches are versus 2.5.40, and still reflect the original design decision of allowing ext2 and ext3 ACL support to be available as separate standalone modules. (See the discussion of the EA patches about whether or not this makes sense.)

Please comment/bleed on these patches.