ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.12-rc3/2.6.12-rc3-mm1/

• There's still a bug in the new timer code. If you think you hit it, please revert

          timers-fixes-improvements-fix.patch                     then
          timers-fixes-improvements-smp_processor_id-fix.patch    then
          timers-fixes-improvements.patch

  or, better, fix the bug.

• If you use mpt-fusion, beware that the CONFIG_* names got changed - if you blindly do `make oldconfig' you won't have any disks.
• ia64 crashes when doing a PM poweroff. It's triggered by properly-stop-devices-before-poweroff.patch but appears to be an ia64 bug.
• Lots of bk trees were dropped and lots of git trees and patch serieses were picked up. I think all the subsystem trees are here, but the bk ones are starting to rot. As far as I can tell, no subsystem maintainers are updating their bk trees (apart from acpi).
• We're still miles away from 2.6.12. Lots of patches here, plus my collection of bugs-post-2.6.11 is vast. I'll start working through them again after 2.6.12-rc4 is available to testers.

If we stick with git it might make sense not to include a linux-patch. cogito is quite fast to export using a commit id. Suspect some bandwidth could be saved if you just stated the commit id that you based the mm patch on.

In case anyone is wondering how build this from a cogito/git db... Find the cogito announcement on lkml install and update cogito. Then folliw the instructions in the README and download the kernel's db. Next search lkml to find the commit id of rc3 (a2755a80f40e5794ddc20e00f781af9d6320fafb) and verify you have it correct with:

cg-mkpatch a2755a80f40e5794ddc20e00f781af9d6320fafb

then export a tree with

cg-export ../12-3-1 a2755a80f40e5794ddc20e00f781af9d6320fafb

and cd over to the new dir and patch with mm and have fun.

I suspect that the majority of people who build -mm kernels build -mm kernels because they *weren't* using BK to pull the trees they were interested in.

Currently I can pull the pieces needed for a -mm kernel over a 56K modem without *too* much pain, which means it's something I can easily do in an evening. What would be the additional disk space requirements to store enough of a git tree so I can pull the corresponding linus.patch myself, and how long would it take to do at 56K? Also, what's the comparative CPU/bandwidth hit on the server end for me to download the additional data if it's bundled into Andrew's patch, versus me doing a 'git update' or whatever the command is?

I'm suspecting that it's less strain overall to just include the 180K or so that the bzip'ed linus.patch takes than to make everybody pull the data needed to create their own linus.patch

The reasons why I for one do not plan to use git are:

• disk space
• bandwidth (rsync traffic has to go through our masquerader, and the amount of traffic through the masquerader I'm allowed to generate is limited)
• I do not need Linus' tree for anything. I'm working against -mm because it's further in development.

Having said this, Andrew might perhaps be able to _additionally_ provide -mm patches without linus.patch for the convenience of git users.

Nope. At any particular point in time the tree I have here has lots of problems - failing to compile, crashing, etc. It takes me from four hours to three days just to get a halfway-respectable release out the door.

So there's no way in which I'd want to make the tree-of-the-minute externally available - it would muck people around too much and would cause me to get a ton of email about stuff which I'd probably already fixed.

That, plus a traditional SCM is an inappropriate format for something like -mm. This tree is a series of patches against Linus's tree - that's how it is developed, tested and sent upstream. Patches get added, dropped, reordered and merged at any time. It's hard to explain - you need to have used patch-scripts or quilt for a while...

Prematurely flattening all this into an SCM view is a fairly pointless exercise - the only reason for doing it would be for people to be able to download it. And they can do that by grabbing the single diff anyway. I suppose someone might start offering git -mm trees sometime, as an alternative to grabbing the diff file.

I think I've got this set up right. I have created a HEAD-for-linus and HEAD-for-mm in the same git repo.

I've got one patch that I'd like in 2.6.12, and I've got some cleanups that can just stay in -mm for now.

Please pull from

rsync://rsync.kernel.org/pub/scm/linux/kernel/git/shaggy/jfs-2.6.git/HEAD-for-linus

I already changed my scripts to be able to do that. They default to HEAD, but if you tell them something else, they'll get that instead.

So I'd do a

git-pull-script foo://.../libata-2.6.git/ HEAD-for-linus

except right now my pull script only works with rsync or ssh, not http. I'll fix that up asap.

sg3_utils is a package of command line utilities for sending SCSI commands to devices. This package targets the lk 2.6 and lk 2.4 series. In the lk 2.6 series these utilities (except sgp_dd) can be used with any devices that support the SG_IO ioctl.

This version adds sg_rmsn to read media serial number(s). The tarball contains a spec file for building rpms. That spec file builds two binary rpms: sg3_utils and libsgutils. In the future my plan is to make other utilities such as sdparm depend on libsgutils. See CHANGELOG for other changes.

A tarball, rpm and deb can be found on (see table 2): http://www.torque.net/sg

For an overview of sg3_utils see this page: http://www.torque.net/sg/u_index.html

The sg_dd utility has its own page at: http://www.torque.net/sg/sg_dd.html

A changelog can be found at: http://www.torque.net/sg/p/sg3_utils.CHANGELOG

sdparm is a command line utility designed to get and set SCSI disk parameters (cf hdparm for ATA disks). More generally it gets and sets mode page information on SCSI devices or devices that use a SCSI command set (e.g. CD/DVD drives (any transport) and SCSI tape drives). It also can list device identification descriptors from VPD pages.

For more information and downloads (tarball, rpms and deb packages) see: http://www.torque.net/sg/sdparm.html

This utility overlaps in functionality somewhat with blktool by Jeff Garzik.

sdparm 0.90 was the original version released. ChangeLog for sdparm-0.91 [20050506]

• if lk 2.4 detected, map primary SCSI node to sg node for ease of use
• add support for '--inquiry' (VPD pages, defaults to device identification)
• decode format and rigid disk mode pages (sbc2) [both pages are obsolete but common]

git trees, patches, tar-balls, you name it. I've still not made a shortlog script, and right now I'm too tired to generate the shortlog from the full log, so you can either find it all in the git archives, or just parse down the full log in ChangeLog-2.6.12-rc4 to a more manageable format.

Both the full log and the diffstat are too big for the mailing list to accept, so I'll not spam your mailboxes.

But you could just use gitweb, in case you haven't noticed already. So point your browsers at http://www.kernel.org/git and see what you find out that way.

What's changed? ia64, arm, UML, ppc64, jfs, cifs updates. And drivers. And tons of small stuff all over.

Me, I'm off for a week of vacationing. Flee the country, like I usually do after releases. Leave you suckers^H^H^H^H^H^H^Hgentle people to test it all out.

Version 0.0.7 of yaird is now available at:

http://www.xs4all.nl/~ekonijn/yaird/yaird-0.0.7.tar.gz

Yaird is a proof of concept perl rewrite of mkinitrd. It aims to reliably identify the necessary modules by using the same algorithms as hotplug, and comes with a template system to to tune the tool for different distributions and experiment with different image layouts. It requires a 2.6 kernel with hotplug. There is a paper discussing it at:

http://www.xs4all.nl/~ekonijn/yaird/yaird.html

Summary of user visible changes:

• Support cryptsetup-luks (Based on a patch by Dick Middleton)

• Bugfixes

  • cryptsetup, handle multiple hard links to same block special dev
  • cryptsetup, recognise keyword 'none' in /etc/crypttab
  • cryptsetup, keyfile check now for both luks and plain
  • cryptsetup, missing module for aes-cbc-essiv:sha256
  • Fedora template: dash was used instead of ash

On top of the todo list are now:

• support NFS devices
• support loopback devices

I'm pleased to announce a new project related to Linux kernel tunables. Any comment you have will be welcome!

Automatic Kernel Tunables Project

The AKT (Automatic Kernel Tunables) project aims at:

1. providing a standard API to unify the various ways Linux developers have to access kernel tunables, system information, resource consumptions: today, installation scripts, supervision scripts and more generally applications are facing the following issues:

   • There are quite multiple ways of accessing the kernel configuration and tunables: /procfs, /sysfs, sysconf(), rlimit(), etc...,
   • The associated executables are rarely portable, since they require to get, set and change values that are represented by objects that may change from distribution to distribution, or from one release to the other inside the same distribution.

   This raises the need for a standard, well defined API to manipulate the kernel configuration and tunables for software products to relay on. This API will be built on top of the existing mechanisms: it will "hide" them instead of replacing them, in order not to break backward compatibility.

2. making the kernel able to automatically tune the resources as it sees appropriate. This is a much more complicated feature that will be considered as a second step for the project

A design about 1st point will be available soon at http://akt.sourceforge.net/. Everything related to this project will be dropped at this url, and further discussions will take place in the dedicated project mailing lists at SF.

Due to a recently announced security issue with the current kernel, we (the -stable team) are announcing the release of the 2.6.11.9 kernel. It contains:

• a fix for the posted problem
• a revert of a patch in the last release that caused issues with partitions (the bk changelog shows this as a i2c issue, but that is a mistake as you can see from the real patch.)
• addition of the SecurityBugs documentation
• another security related fix that is already in 2.6.12-rc4.

The diffstat and short summary of the fixes are below.

I'll also be replying to this message with a copy of the patch between 2.6.11.8 and 2.6.11.9, as it is small enough to do so.

Here goes 2.4.31-pre2.

It contains a small number of changes, most notably the elf_core_dump flaw fix (CAN-2005-1263).

Please refer to -hf tree for the standalone patch.

http://linux.exosec.net/kernel/2.4-hf/

I have finally gotten around to getting 2.6.x libata development moved over from BitKeeper to git.

The "for Linus/Andrew" repository is libata-2.6.git, available at rsync://rsync.kernel.org/pub/scm/linux/kernel/git/jgarzik/libata-2.6.git/

The new libata-dev repository is libata-dev.git, available at rsync://rsync.kernel.org/pub/scm/linux/kernel/git/jgarzik/libata-dev.git/

A word about these repositories. I don't use any SCM besides git itself. libata-2.6.git appears as you would expect: .git/HEAD points to refs/heads/master, which is the top-of-tree, and contains patches destined for upstream ASAP.

libata-dev.git is a bit different, as it contains multiple branches:

>[jgarzik@pretzel libata-dev]$ ls .git/refs/heads/
>adma        atapi-enable        iomap        pdc2027x
>adma-mwi    bridge-detect       iomap-step1  pdc20619
>ahci-atapi  chs-support         master       promise-sata-pata
>ahci-msi    ioctl-get-identity  passthru     sil24

I use the attached 'git-switch-tree' script to update the working directory to reflect the desired branch.

As soon as I am comfortable with git merging, I will create an 'ALL' branch, which contains all of these trees, merged together properly.