Kernel Traffic #190 For 28 Oct 2002

This patch, in conjunction with the "core" high-res-timers patch implements high resolution timers on the i386 platforms. The high-res-timers use the periodic interrupt to "remind" the system to look at the clock. The clock should be relatively high resolution (1 micro second or better). This patch allows configuring of three possible clocks, the TSC, the ACPI pm timer, or the Programmable interrupt timer (PIT). Most of the changes in this patch are in the arch/i386/time.c code.

This patch uses (if available) the APIC timer(s) to generate 1/HZ ticks and sub 1/HZ ticks as needed. The PIT still interrupts, but if the APIC timer is available, just causes the wall clock update. No attempt is made to make this interrupt happen on jiffie boundaries, however, the APIC timers are disciplined to expire on 1/HZ boundaries to give consistent timer latencies WRT to the system time.

With this patch applied and enabled (at config time in the processor feature section), the system clock will be the specified clock. The PIT is not used to keep track of time, but only to remind the system to look at the clock. Sub jiffies are kept and available for code that knows how to use them.

the notion is to provide timers that have resolution down into the micro seconds. Since this take a bit more overhead, we just set up an interrupt on an as needed basis. This is why we define both a high res and a low res clock. Timers on the low res clock will always use the 1/HZ tick to drive them and thus do not introduce any additional overhead. If this is all that is needed the configure option can be left off and only these timers will be available.

On the other hand, if a user requires better resolution, s/he just turns on the high-res option and incures the overhead only when it is used and then only at timer expire time. Note that the only way to access a high-res timer is via the POSIX clocks and timers API. They are not available to select or any other system call.

Making ticks shorter causes extra overhead ALL the time, even when it is not needed. Higher resolution is not free in any case, but it is much closer to free with this patch than by increasing HZ (which, of course, can still be done). Overhead wise and resolution wise, for timers, we would be better off with a 1/HZ tick and the "on demand" high-res interrupts this patch introduces.

How about changing the definition to:

#define current ((struct task_struct *)get_current())

That should get the same effect as currently for kernel code, but will guarantee a syntax error if it's used in a structure declaration.

current.h is, indeed, a special case. #define i j would not be tolerated simply because it's stupid. Abuses of preprocessor are generally frowned upon, but there are passionate wa^H^Hpersons who just can't help themselves and use e.g. ## for no good reason.

But as for C++... frankly, for all I care it doesn't exist. As long as requirements of style happen to reduce problems of C++ programmers - they are lucky. But other than that... watch me not care. In the linux kernel context C++ is obscure language and it will stay that way. Ergo, no reasons to spend any mental efforts on being nice to it. Deal.

A huge merging frenzy for the feature freeze, although I also spent a few days getting rid of the need for ide-scsi.c and the SCSI layer to burn CD-ROM's with the IDE driver (it still needs an update to cdrecord, I sent those off to the maintainer).

The most fundamental stuff is probably RCU and oprofile, but there's stuff all over the map here..

Anyway, ide-scsi should work as well as it ever did, which is not to say too well. It's just that the IDE native implementation is cleaner and simpler, and a _hell_ of a lot easier to use.

The scsi-generic layer is a total nightmare. If you want to write to the device that is /dev/scd0, you can't just use /dev/scd0, you have to use the right /dev/sgX, and the X depends on how many disks etc you have in the system and where your controller is. The amount of crap you have to do with things like "cdrecord -scanbus" to just figure out what the right device is is just ludicrous.

With the native IDE setup, if your CD is /dev/hdc, then that's what you use for cdburning too. Just do "cdrecord dev=/dev/hdc" and that's it. No made-up SCSI bus numbers, no need to try to figure out what the right thing is, no crap.

In fact, I hope that in linux-2.7.x the SCSI layer itself will start using the same interface, so that we can drop scsi-generic some day completely. The interface is totally generic, and doesn't have anything to do with IDE per se - ide-cd.c just needed to be cleaned up enough to be able to use it. The interface really just says "hey, you can push SCSI commands down the request queue" (and ide-cd.c will take the SCSI command and convert it into an ATAPI packet command - which is a pretty trivial transform).

So right now, you can do "cdrecord dev=/dev/hdc ..", but because I didn't bother to try to figure out what the SCSI layer wants to do you can _not_ do the simple "cdrecord dev=/dev/scd0 .." if you have a SCSI disk. That's nothing fundamental, I just don't think SCSI CD-RW's are very interesting any more, since they are overpriced and hard to find. I hope some SCSI fanatic will do the (probably trivial) addition to sr.c to accept the SCSI ioctl interface.

(Hint for such SCSI users: you should just do:

• call "scsi_cmd_ioctl()" in your ioctl routine, and if it returns ENOTTY that means that it wasn't one of the SCSI generic commands.
• make the request queue handler understand that requests with the REQ_BLOCK_PC flag set are SCSI packet commands, and "req->cmd" contains the command, while "req->data" and "req->data_len" are the data for the command)
• make sure that an open() with the O_NONBLOCK flag set will succeed even if the medium is not accessible (and will succeed even if it's a writable open).

and that should be pretty much it).

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.

LinSec team is proud to announce first stable release of LinSec.

LinSec, as the name says, is Linux Security Protection System. The main aim of LinSec is to introduce Mandatory Access Control (MAC) mechanism into Linux (as opposed to existing Discretionary Access Control mechanism). LinSec model is based on:

• Capabilities
• Filesystem Access Domains
• IP Labeling Lists
• Socket Access Control

As for Capabilities, LinSec heavily extends the Linux native capability model to allow fine grained delegation of individual capabilities to both users and programs on the system. No more allmighty root!

Filesystem Access Domain subsystem allows restriction of accessible filesystem parts for both individual users and programs. Now you can restrict user activities to only its home, mailbox etc. Filesystem Access Domains works on device, dir and individual file granularity.

IP Labeling lists enable restriction on allowed network connections on per program basis. From now on, you may configure your policy so that no one except your favorite MTA can connect to remote port 25

Socket Access Control model enables fine grained socket access control by associating, with each socket, a set of capabilities required for a local process to connect to the socket.

LinSec consists of two parts: kernel patch (currently for 2.4.18) and userspace tools.

Detailed documentation, download & mailing list information - http://www.linsec.org

O.k. My first pass at getting up to date with the current kernel is available at:
http://www.xmission.com/~ebiederm/files/kexec/linux-2.5.42.kexec.x86.diff
http://www.xmission.com/~ebiederm/files/kexec/kexec-tools-1.0.tar.gz

The big changes are:

1. I have rebundled my tools so it is a little easier to get at:
2. I have included a test case kexec_test that tests the stranger cases, so when the kernel doesn't boot, we can rule out the kexec code.
3. I have added a call to device_shutdown so device drivers get a chance to shut up.
4. I have moved kexec into its one system call instead of treating sys_reboot like an ioctl. The big reason is that while there is a lot of generic code some very architecture specific code must be written for each architecture, and having to register a system call means the code won't become active by accident.

I will probably split this up before sending to Linus but anyway, here is the patch so you can pick it apart and tell me what you don't like.

the attached patch is the second iteration of thread-aware coredumps, against BK-curr. I think this patch is now ready for inclusion into mainline.

Changes:

• Ulrich Drepper has reviewed the data structures and checked actual coredumps via readelf - everything looks fine and according to the spec.
• a serious bug has been fixed in the thread-state dumping code - it was still based on the 2.4 assumption that the task struct points to the kernel stack - it's task->thread_info in 2.5. This bug caused bogus register info to be filled in for threads.

• properly wait for all threads that share the same MM to serialize with the coredumping thread. This is CLONE_VM based, not tied to CLONE_THREAD and/or signal semantics, ie. old-style (or different-style) threaded apps will be properly stopped as well.

  The locking might look a bit complex, but i wanted to keep the __exit_mm() overhead as low as possible. It's not quite trivial to get these bits right, because 'sharing the MM' is detached from signals semantics, so we cannot rely on broadcast-kill catching all threads. So zap_threads() iterates through every thread and zaps those which were left out. (There's a minimal race left in where a newly forked child might escape the attention of zap_threads() - this race is fixed by the OOM fixes in the mmap-speedup patch.)

• fill_psinfo() is now called with the thread group leader, for the coredump to get 'process' state.
• initialize the elf_thread_status structure with zeroes.

the IA64 ELF bits are not included, yet, to reduce complexity of the patch. The patch has been tested on x86 UP and SMP.

2.5.43 versions of CSA, Job, and PAGG patches are available at:

ftp://oss.sgi.com/projects/pagg/download/linux-2.5.43-pagg-job.patch

ftp://oss.sgi.com/projects/csa/download/linux-2.5.43-csa.patch

The CSA and job user-level code is in the same directories.

CSA (Comprehensive System Accounting) provides methods for collecting per-process resource usage data, monitoring disk usage, and charging fees to specific login accounts. CSA provides features which are not available with the other Linux accounting packages. For more information, see:

http://oss.sgi.com/projects/csa/

Linux Jobs is an inescapable process container that is typically created by point of entry processes like login, and inherited by children. PAGG (Process Aggregates) is a generic framework for implementing process containers such as Linux Jobs. For more information, see:

http://oss.sgi.com/projects/pagg/

CSA depends on Linux Jobs, and Linux Jobs depends on PAGG.

Attached is a patch for generic AGP 3.0 device detection and enabling routines as well as specific support for the Intel 7505 chipset against the 2.5.43 kernel.

This patch adds a new file agp3.c which contains generic enabling and detection routines based on the AGP 3.0 spec. Some of the new features include detection of multiple devices and proper isochronous bandwidth allocation to each discovered device, as well as the typical host bridge initialization. This patch also adds another file i7505-agp.c which contains the chipset specific support. It is prudent to note that this patch does not yet implement all of the capabilities defined by the AGP 3.0 spec.

A new development version of LTT is now available, 0.9.6pre2. Here's what's new:

• Per-CPU buffering
• TSC timestamping
• Use of syscall interface instead of char dev abstraction

The release includes a patch for 2.5.43 which is pretty much ready for inclusion. I will be posting this patch raw ot the LKML with a more verbose description.

You will find 0.9.6pre2 here:
http://www.opersys.com/ftp/pub/LTT/

LTT's web site is here:
http://www.opersys.com/LTT

The problem is that the kernel patch is highly dependent on the kernel's own development. The tracing infrastructure has to change as the kernel changes. Incidently, the user tools also have to change to accomodate the newer kernels. There's a point where keeping compatibility with older kernels becomes increasingly difficult and would entail one of two things:

• Burden the user tools with legacy support.
• Backport all new features to older kernels.

Neither of these is really interesting. Of course, if someone wants to take the time to backport some of the new features to older kernels I would gladly publish their patch with the tools. The time it takes to work out an LTT patch is non-negligeable and I don't have the bandwidth to maintain multiple kernel patches in parallel. This is why I'm concentrating on getting LTT to work with the latest and greatest.

Obviously things will be much simpler once the LTT patch is included in the kernel.

Release 1.0.24 of JFS was made available today.

Drop 62 on October 18, 2002 (jfs-2.4-1.0.24.tar.gz and jfsutils-1.0.24.tar.gz) includes fixes to the file system and utilities.

Utilities changes

• byte-swapping fixes for big-endian hardware (fixes in logredo and fsck.jfs)

File System changes

• readSuper() was incorrectly checking return status of sb_bread()
• change name of get_index to read_index fixes MIPS build issue
• Releasing LOGGC_LOCK too early
  In txLazyCommit, we are releasing log->gclock (LOGGC_LOCK) before checking tblk->flag for tblkGC_LAZY. For the case that tblkGC_LAZY is not set, the user thread may release the tblk, and it may be reused and the tblkGC_LAZY bit set again, between the time we release the spinlock until we check the flag. This problem is easy to hit on a 2.5 kernel with CONFIG_PREEMPT set, but it is a potential problem on SMP as well. The fix is to hold the spinlock until after we've checked the flag.

For more details about JFS, please see the patch instructions or changelog.jfs files.

JFS for Linux http://oss.software.ibm.com/jfs

This patch adds SMP (and UP) support for voyager which is an (up to 32 way) SMP microchannel non-PC architecture.

The current patch includes a swap around of the timer code defines (available separately at http://linux-voyager.bkbits.net/timer-2.5) and a new CONFIG_X86_TRAMPOLINE config option to avoid the trampoline vpath.

The patch (156k) is available here:

http://www.hansenpartnership.com/voyager/files/voyager-2.5.44.diff

And also via bitkeeper at

http://linux-voyager.bkbits.net/voyager-2.5

You mean how the VIC boots? Certainly. Referring to the architecture in

http://www.hansenpartnership.com/voyager/L5arch.html

The VIC is basically a set of 8258 dyads (and voyager has up to 8 of them). The boot CPU can send a cross processor interrupt (CPI) to any VIC connected CPU. However, the boot CPU can only modify its own VIC 8258 dyad, so theres a masquerade register that temporarily globally drives the VIC processor ID lines so that the boot CPU can lower the interrupt mask in a different VIC.

However, each CPU card has only one or two VIC connections, so booting the Quad cards is a sort of one-two trick: you VIC boot the VIC connected CPU (called the extended CPU) and then it QIC (Quad interrupt controller) boots the remaining CPUs. The QIC works using a cache line interference mechanism (so writes to a particular part of memory trigger the CPI). However, only CPUs local to the Quad can masquerade as each other to lower the QIC interrupt mask.

An updated uClinux patch is available at:

http://www.uclinux.org/pub/uClinux/uClinux-2.5.x/linux-2.5.44uc0.patch.gz

Changelog:

1. patched against 2.5.44

Smaller specific patches:

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

This patch updates UML to 2.5.44.

The only UML-specific change in this patch is the merge of some of James McMechan's ubd driver changes which make partitions work again.

The patch is available at
http://uml-pub.ists.dartmouth.edu/uml/uml-patch-2.5.44-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

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

• The shared pagetable code is back in. Seems to be stabilising. If anyone has any weird problems, please see if a `patch -R -p1 < shpte-ng.patch' fixes it up, thanks.

• There have been ongoing travails in the direct-io code since the introduction of bio_add_page().

  It was all turning into a bit of a pickle, so I got down and rewrote the file-walk, assembly and BIO submission phase in a manner which suits the bio_add_page() semantics. This version is, IMO, significantly clearer. And it now runs the modified-for-O_DIRECT fsx-linux code without going BUG.

  This of course broke the allow-512-byte-alignment patch; that needs to be redone.

• There is a series of debloat patches here. Expect to see the kernel use 100k less memory on UP and 300k less on SMP.

  Well, more accurately 10k * (NR_CPUS - number_of_cpus).

• A series of updates from Bill on the large page filesystem and shm patches
• I'm carrying ninety five diffs here. People who send me patches for integration: please, keep it as small as is practical, and not trivial stuff. Thanks.

I finally got around to documenting the scripts which I use for managing kernel patches. See

http://www.zip.com.au/~akpm/linux/patches/patch-scripts-0.1/

These scripts are designed for managing a "stack" of patches against a rapidly-changing base tree. Because that's what I use them for.

I've been using and evolving them over about six months. They're pretty fast, and simple to use. They can be used for non-kernel source trees.

The implementation is pretty agricultural - I only know how to do three things in /bin/sh scripts and I'm not sure that I want to learn #4, but patches are accepted.

Hopefully these will be useful to some people. I'd expect that the ramp-up time is half an hour or so.

Here's the fine manual:

This is a description of a bunch of shell scripts which I use for
managing kernel patches.  They are quite powerful.  They can be used on
projects other than the linux kernel.  They are easy to use, and fast.

You end up doing a ton of recompiling with these scripts, because
you're pushing and popping all the time.  ccache takes away the pain of
all that.  http://ccache.samba.org/ - be sure to put the cache
directory on the same fs as where you're working so that ccache can use
hardlinks.

The key philosophical concept is that your primary output is patches.
Not ".c" files, not ".h" files.  But patches.  So patches are the
first-class object here.


Concepts
========

All work occurs with a single directory tree.  All commands are invoked
within the root of that tree.  The scripts manage a "stack" of patches.

Each patch is a changeset against the base tree plus the preceding patches.

All patches are listed, in order, in the file ./series.  You manage the
series file.

Any currently-applied patches are described in the file
./applied-patches.  The patch scripts manage this file.

Each patch affects a number of files in the tree.  These files are
listed in a "patch control" file.  These .pc files live in the
directory ./pc/

Patches are placed in the directory ./patches/

Documentation for the patches is placed in ./txt/

So for a particular patch "my-first-patch" the following will exist:

- An entry "my-first-patch.patch" in ./series

- An entry "my-first-patch" in ./applied-patches (if it's currently applied)

- A file ./pc/my-first-patch.pc which contains the names of the
  files which my-first-patch modifies, adds or removes

- A file ./txt/my-first-patch.txt which contains the patch's
  changelog.

- A file ./patches/my-first-patch.patch, which is the output of the
  patch scripts.

Operation
=========

When a patch "my-patch" is applied with apatch, or with pushpatch
(which calls apatch), all the affected files (from ./pc/my-patch.pc)
are copied to files with ~my-patch appended.  So if ./pc/my-patch.pc
contained

        kernel/sched.c
        fs/inode.c

then apatch will copy those files into kernel/sched.c~my-patch and
fs/inode.c~my-patch.  It will then apply the patch to kernel/sched.c
and fs/inode.c

When a diff is regenerated by refpatch (which calls mpatch), the diff
is made between kernel/sched.c and kernel/sched.c~my-patch.  How do the
scripts know to use "~my-patch"?  Because my-patch is the current
topmost patch.  It's the last line in ./applied-patches.

In this way, the whole thing is stackable.  If you have four patches
applied, say "patch-1", "patch-2", "patch-3" and "patch-4", and if
patch-2 and patch-4 both touch kernel/sched.c then you will have:

        kernel/sched.c~patch-2          Original copy, before patch-2
        kernel/sched.c~patch-4          Copy before patch-4.  Contains changes
                                        from patch-2
        kernel/sched.c                  Current working copy.  Contains changes
                                        from patch-4.

This means that your diff headers contain "~patch-name" in them, which
is convenient documentation.

Walkthrough
===========

Let's start.

Go into /usr/src/linux (or wherever)

        mkdir pc patches txt

Now let's generate a patch

        fpatch my-patch kernel/sched.c

OK, we've copied kernel/sched.c to kernel/sched.c~my-patch.  We've
appended "my-patch" to ./applied-patches and we've put "kernel/sched.c"
into the patch control file, pc/my-patch.pc.

        Now edit kernel/sched.c a bit.

Now we're ready to document the patch

        Now write txt/my-patch.txt

Now generate the patch

        refpatch

This will generate patches/my-patch.patch.  Take a look.

Now remove the patch

        poppatch

applied-patches is now empty, and the patch is removed.

Now let's add a file to my-patch and then generate my-second-patch:

        Add "my-patch.patch" to ./series (no blank lines in that file please)

        pushpatch

OK, the patch is applied again.  Let's add another file

        fpatch kernel/printk.c

Note that here we gave fpatch a single argument.  So rather than
opening a new patch, it adds kernel/printk.c to the existing topmost
patch.  That's my-patch.

        Edit kernel/printk.c

Refresh my-patch (you end up running refpatch a lot)

        refpatch

Now start a second patch:

        fpatch my-second-patch kernel/sched.c

Now take a look at applied-patches.  Also do an `ls kernel/sched*'.

        Edit kernel/sched.c, to make some changes for my-second-patch

Generate my-second-patch:

        refpatch

Take a look in patches/my-second-patch.patch

Don't forget to add "my-second-patch.patch" to the series file.

And remove both patches:

        poppatch
        poppatch


That's pretty much it, really.


Command reference
=================

Generally, where any of these commands take a "patch-name", that can be
of the form txt/patch-name.txt, patch-name.pc, just patch-name or
whatever.  The scripts will strip off a leading "/kernel-traffic/txt/index.html", "/kernel-traffic/patches/index.html" or
"/kernel-traffic/pc/index.html" and any trailing extension.  This is so you can do

        apatch patches/a<tab>

to conveniently use shell tabbing to select patch names.



added-by-patch

  Some internal thing.

apatch [-f] patch-name

  This is the low-level function which adds patches.  It does the
  copying into ~-files and updates the applied-patches file.  It
  applies the actual patch.

  apatch will do a patch --dry-run first and will refuse to apply the
  patch if the dryrun fails.

  So when you are getting rejects you do this:

        pushpatch               # This fails, due to rejects.  Drat.
        apatch -f patch-name    # Force the patch

  OK, you've now applied patch-name, but you have rejects.  Go fix
  those up and do

        refpatch

  And you're ready to move on.

cvs-take-patch

  I forget.

fpatch [patch-name] foo.c

  If patch-name is given, fpatch will start a new patch which
  modifies (or adds, or removes) the single file foo.c.  It updates
  ./applied-patches and creates pc/patch-name.pc.  fpatch will copy
  foo.c to foo.c~patch-name in preparation for edits of foo.c.

  If patch-name is not given then fpatch will add foo.c to the
  current topmost patch.  It will add "foo.c" to ./pc/$(toppatch).pc.
  It will copy foo.c to foo.c~$(toppatch).

inpatch

  List the names of ths files which are affected by the current
  topmost patch.

  This is basically

        cat pc/$(toppatch).pc

mpatch

  A low-level thing to generate patches

new-kernel

  Some thing I use for importing a new kernel from kernel.org

p0-2-p1

  Internal thing to convert patch -p0 form into patch -p1

patchdesc

  Generates a single-line description of a patch.

  The txt/my-patch.txt files have the following format:

  <start of file>
  DESC
  some short description
  EDESC

  The long description
  <end of file>

  I use

        patchdesc $(cat series)

  to generate short-form summaries of the patch series.

patchfns

  Internal utilities

pcpatch

  Standalone tool to generate a .pc file from a patch.

  Say someone sends you "his-patch.diff".  What you do is:

        cp ~/his-patch.diff patches/his-patch.patch
        pcpatch his-patch

  This generates ./pc/his-patch.pc and you're all set.  Add
  "his-patch.patch" to ./series in the right place and start pushing.

p_diff

  I forget

poppatch

  Remove one or more patches fro the current stack.  This command
  does *not* use the series file.  It works purely against
  applied-patches.

  Usage:

        poppatch
                Remove the topmost patch
        poppatch 10
                Remove ten patches
        poppatch some-patch-name[.patch]
                Remove patches until "some-patch-name" is top patch

ptkdiff

  Two modes:

        ptkdiff -

               Run tkdiff against all the file affected
               by $(toppatch).  The diff is only for the changes made
               by the top patch! ie: it's between "filename" and
               "filename~toppatch-name".

        ptkdiff filename

               Just run tkdiff against that file,
               showing the changes which are due to toppatch.

pushpatch

  Apply the next patch, from the series file.

  This consults ./applied-patches to find out the top patch, then
  consults ./series to find the next patch.  And pushes it.

    pushpatch

      Apply the next patch

    pushpatch 10

      Apply the next ten patches

    pushpatch some-patch-name

      Keep pushing patches until "some-patch-name" is toppatch

refpatch

    regnerates the topmost patch.  Reads all the affected files
    from pc/$(toppatch).pc and diffs them against their tilde-files.

    Also pastes into the patch your patch documentation and
    generates a diffstat summary.

removed-by-patch

  Some thing.

rename-patch

  CVS rename for patches.

rolled-up-patch

  Bit of a hack.  Is designed to generate a rolled-up diff of all
  currently-applied patches.  But it requires a ../linux-2.x.y tree to
  diff against.  Needs to be redone.

rpatch

  Internal command

split-patch

  Some thing someone write to split patches up.  I don't use it.

toppatch

  Print the name of the topmost patch.  From ./applied-patches

touched-by-patch patch-filename

  List the names of files which are affected by a diff.

unitdiff.py

  Rasmus Andersen's script to convert a diff into minimum-context
  form.  This form has a better chance of applying if you're getting
  nasty rejects.  But patch can and will make mistakes when fed
  small-context input.


Work Practices
==============

I keep the kernel tree, the ./pc/, ./patches/ and ./txt/ contents under
CVS control.  This is important...

I have several "series" files.  I keep these in ./pc/foo-series and use

        ln -s pc/foo-series series

when I'm working on foo.

If someone sends me a patch I'll do:

        cp ~/whatever patches/his-patch.patch
        pcpatch his-patch
        apatch his-patch

  If apatch fails then run `apatch -f his-patch' and fix the rejects.

        refpatch

  to clean up any fuzz.

        poppatch
        cvs add pc/his-patch.pc patches/his-patch.patch
        cvs commit pc patches

  Now edit ./series and place "his-patch.patch" in the appropriate place.

If you're working on a particular patch (say, "dud-patch") and you
balls something up, just run:

        refpatch        # Generate the crap patch
        poppatch        # Remove it all
        rm patches/dud-patch.patch
        cvs up patches/dud-patch.patch

and all is well.


Getting updates from Linus
==========================

What I do is to grab the latest -bk diff from
http://www.kernel.org/pub/linux/kernel/people/dwmw2/bk-2.5/
and do:

        gzip -d < cs<tab> > patches/linus.patch
        pcpatch linus
        apatch linus | grep diff

               Now fix up all the files which got deleted,
               because there's something wrong with bitkeeper diffs:

        cvs up -ko <missing files from the above diff>

        apatch linus
        $EDITOR linus/linus.txt

                Add the changeset number to txt/linus.txt

        refpatch
        poppatch

  Now add "linus.patch" as the first entry in your ./series file and
  start pushing your other patches on top of that.

BUGS
====

Tons and tons.  The scripts are fragile, the error handling is ungraceful and
if you do something silly you can end up in a pickle.

Generally the scripts are very careful to not wreck your files or your
patches.  But they can get the ./applied-patches and ~-files into an
awkward state.

Usually you can sort it out by copying the ~-files back onto the originals
and removing the last line from ./applied-patches.  Or do a "refpatch ;
poppatch ; rm patches/troublesome-patch.patch ; cvs up patches".

If it's really bad, just blow away the entire tree and do a new CVS checkout.


Working on non-kernel projects
==============================

Well it's the same thing.  Say you've downloaded a copy of util-linux
and you want to make a change:

        cd /usr/src
        tar xvfz ~/util-linux.tar.gz
        cd util-linux
        mkdir pc patches txt
        fpatch my-patch sys-utils/rdev.c
        fpatch sys-utils/ipcs.8
        <edit, edit>
        refpatch
        <ship patches/my-patch.patch>

How to balls things up
======================

Well here's one way.  Suppose you have 20 patches applied, and three of
them (say, "p1", "p6" and "p11") all modify "foo.c".

Now you go and change foo.c.

Well, to which patch does that change belong?  You need to decide.
Let's say you decide "p6".

If you run `refpatch' when "p11" is toppatch then you lose.  The diff
went into p11.

What you can do is:

1:
        poppatch p6
        <edit>
        refpatch
        pushpatch p11
        <test>

  (See why ccache is looking good?)

or

2:
        <edit>
        <test>
        poppatch p6     <hope like hell that the other patches remove cleanly>
        refpatch


Another good way of ballsing up is to cheat.  Say "oh I just want to make
this one-line change".  And "oh, and this one".

Now you're getting in a mess.  It's much, much better to just use the system:

        fpatch junk file1
        fpatch file2
        <edit>
        <play>
        refpatch
        poppatch
        rm pc/junk.pc patches/junk.patch

Merging with -mm kernels
========================

Haven't tried this, but it should work:

- Grab all the patches from broken-out/, place them in your ./patches/

- Copy my series file into ./series (or ./pc/akpm-series and symlink it)

- pushpatch 99

And you're off and running.  The nice thing about this is that you can
send me incremental diffs to diffs which I already have.

Or whatever.  I'm fairly handy with diffs nowadays.  Rejects are
expected.  I just prefer to have "one concept per diff".

That has always seemed unnatural to me. By keeping everything in the one tree you can easily:

• collapse patches together:

          pushpatch first-patch
          for i in $(cat pc/second-patch.pc)
                  fpatch $i
          done
          patch -p1 < patches/second-patch.patch
          refpatch

• Reorder patches (edit series file, poppatch 10; pushpatch 10)

• Remove a patch which is partway down the stack:

  rpatch patch-7-out-of-10

• make changes to a not-topmost patch without having to do anything special.

Dunno. There are probably ways of doing all these things with a whole-tree copy, but I haven't tried to plot it all out.

Changelog tracking is fairly important to me also.

mnm:/usr/src/25> ls -l txt|wc -l
    560

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

• update to 2.5.44
• new qconf option, which enables some debug output in the help window

The only big change this time is that I added a SWIG interface, which allows to generate a extension library for your favourite script language. I did this already for ruby, 'make ruby' builds the library kconfig.so in the .ruby subdir. I also included some examples.

Okay, Linus has left for the Linux Lunacy Cruise (see www.geekcruises.com), which ends october 27. When he gets back, he's implied that there will be EXACTLY ONE more set of last minute merges before we switch over to the 3.0-pre (or 2.6-pre) series. Those of you waiting for the last minute: this is it.

There are people patch-hoovering while Linus is off "lecturing" on a boat in the carribean, but we don't know who those are, so that's not useful. What IS useful is knowing what the candidate patches are. Not bug fixes, but new features with one final shot at 2.5.45.

• in -ac PCMCIA Zoom video support (Alan Cox)
  http://www.uwsg.iu.edu/hypermail/linux/kernel/0203.1/0326.html
• in -ac Device mapper for Logical Volume Manager (LVM2) (LVM2 team)
  http://www.sistina.com/products_lvm.htm
• in -mm VM large page support (Many people)
  http://lse.sourceforge.net/
• in -mm Page table sharing (Daniel Phillips, Dave McCracken)
  http://www.geocrawler.com/mail/msg.php3?msg_id=7855063&list=35
  (or possibly here:)
  http://lists.insecure.org/lists/linux-kernel/2002/Oct/6446.html
• Ready - Build option for Linux Trace Toolkit (LTT) (Karim Yaghmour)
  http://www.uwsg.iu.edu/hypermail/linux/kernel/0204.1/0832.html
• Ready - Dynamic Probes (dprobes team)
  http://oss.software.ibm.com/developerworks/opensource/linux/projects/dprobes
• Ready - Zerocopy NFS (Hirokazu Takahashi)
  http://www.uwsg.iu.edu/hypermail/linux/kernel/0204.1/0429.html
• Ready - High resolution timers (George Anzinger, etc.)
  http://high-res-timers.sourceforge.net/
• Ready - EVMS (Enterprise Volume Management System) (EVMS team)
  http://sourceforge.net/projects/evms
• Ready - Linux Kernel Crash Dumps (Matt Robinson, LKCD team)
  http://lkcd.sourceforge.net/
• Ready - Rewrite of the console layer (James Simmons)
  http://linuxconsole.sourceforge.net/

To the above can be added the following recent submission on the list:

• Ready- Kexec, luanch ELF format linux kernel from Linux (Eric W. Biederman)
  http://lists.insecure.org/lists/linux-kernel/2002/Oct/6584.html

That's currently it, that I'm aware of. If your patch isn't on that list, and getting testing by people on linux-kernel (and getting a bunch of satisifed users to go "worked for me!" at it), then you should speak up and GET it on that list, or wait for the next development series.

When Linus comes back, at best he's going to give a thumbs up or thumbs down to each patch currently sitting there in front of him, and then it's on to the feature freeze. He may not take any of them, or he may just take one or two. But the best we can hope to do is present him with a nice (short) list of tested patches. (Remember, the less work Linus has to do, the higher the percentage of it that will actually get done.)

So everybody, try the above patches. If they work for you, say so on this list. It's no guarantee, but Linus has said endorsements from testers can make him feel more comfortable about a patch. Possibly we can collect a list of names of people for whom a patch "worked for me", to add to the list.

If your patch isn't on the list, speak out now. Better yet, post a URL to the latest version. It's "show me the code" time. (Yes, Hans Reiser, this means you. :) There are still 7 days till the end of Linus's cruise, but that's not much time to get guinea pigs to publicly pipe up with a hearty "AOL!" of support for your work...

Again, some of the things on this list won't make it into 3.0. It's just candidates. But everything that is NOT on this list in about 7 days is probably going to become 3.1 material by default.

Speak now, or till 3.1 hold your peace...

It would also be nice to buy the dude his own private jet, but I'm not sure it's a practical suggestion in the short term. :)

Linus has already said he intends to read his mail with the "D" key when he gets back. The point of collating the pending feature list is to pluck stuff out of the mess, shake it off a bit, and present him with a nice menu to make choices from on his return.

Deciding not to include stuff is Linus's perogative. (More than that, it's more or less his JOB in kerneldom, acting as goalie for the main tree.) Once again, we're just trying to make sure nothing gets dropped because he didn't see it rather than because he saw it and went "no".

In the past half-hour, the MMU-less patch and unlimited groups support have been fielded as "ready for 2.5", although I haven't seen URLs to either yet. Add Rusty's three items and we're up to... 19? Plus Hans Reiser said reiser4 will be ready around the 27th, so that's 20.

I don't think half that many will make it into 2.5, but some of them are small, so...

LTT has seen a number of changes since the posting above. Mainly, we've followed the recommendations of quite a few folks from the LKML. Here are some highlights summarizing the changes:
http://marc.theaimsgroup.com/?l=linux-kernel&m=103491640202541&w=2
http://marc.theaimsgroup.com/?l=linux-kernel&m=103423004321305&w=2
http://marc.theaimsgroup.com/?l=linux-kernel&m=103247532007850&w=2

The latest patch is available here:
http://opersys.com/ftp/pub/LTT/ExtraPatches/patch-ltt-linux-2.5.44-vanilla-021019-2.2.bz2
Use this patch with version 0.9.6pre2 of the user tools:
http://opersys.com/ftp/pub/LTT/TraceToolkit-0.9.6pre2.tgz

Another thing I've noticed somebody still hoping to shoehorn into 2.5 is Roman Zippel's new kernel configuration system, which is here:

Announcement:
http://lists.insecure.org/lists/linux-kernel/2002/Oct/6898.html
Code:
http://www.xs4all.nl/~zippel/lc/

That was listed as a "beta" on the status list, I guess at version 1.1, it has now been promoted. (Anything else on the beta that's still trying to make it into 2.5? The 27th is sunday, meaning Linus should be back at transmeta on monday. Assuming 2.4.45 ships on the 31st, that would be the following thursday...)

Ted Tso has also been posting new ext2/ext3 code with extended attributes and access control lists.

Announcement:
http://lists.insecure.org/lists/linux-kernel/2002/Oct/6787.html
Code (chooe your poison):
bk://extfs.bkbits.net/extfs-2.5-update
http://thunk.org/tytso/linux/extfs-2.5

Apparently generic ACL support went into 2.5.3 (the status list again), but I guess it wasn't added to EXT2. I suppose this makes this a good candidate for inclusion then. :)

So, 11 items from the 2.5 status list (in -aa, in -mm, and "ready"), plus kexec, kernelconfig, and ACL for EXT3. I believe this brings the total number of pending patchsets still hoping for 2.5 inclusion to 14.

I can repost the full list if nobody beats me to it, but I think I'll wait to see who else pipes up first. :)

It's mainly there for the other VM/MM/IO developers to integrate against.

Also for getting their more experimental work more testing and exposure.

Also for getting external testing of the performance work which is going into it.

Also for maintainers of other architectures to pick up breakage before things break.

I prefer to only send things which I understand and have tested. So that excludes, say, dcache-rcu and the EA/xattr patches. I did send ext3-htree, but it had big "I haven't tested this" labels all over it.

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

• Some more work on the per-cpu memory arenas
• Added a bunch of fixes to various things courtesy of davem
• Merged up a later version of the EA+ACL code
• Lots of little fixes everywhere.
• Fixed a shared pagetable SMP deadlock

Rule Set Based Access Control (RSBAC) version 1.2.1 has been released. Full information and downloads are available from http://www.rsbac.org

RSBAC is a flexible, powerful and fast open source access control framework for current Linux kernels, which has been in stable production use since January 2000 (version 1.0.9a). All development is independent of governments and big companies, and no existing access control code has been reused.

This version comes with many smaller improvements against 1.2.0 and some new features, e.g.:

• New JAIL module, similar to the FreeBSD Jails functionality, but with extensions like individual IPC compartments.
• Support for all architectures (not all of them tested, feedback is welcome).