Kernel Traffic #311 For 5 Jun 2005

By Zack Brown

Table Of Contents

Mailing List Stats For This Week

We looked at 1769 posts in 10MB. See the Full Statistics.

There were 671 different contributors. 253 posted more than once. The average length of each message was 95 lines.

The top posters of the week were: The top subjects of the week were:
75 posts in 386KB by andrew morton
55 posts in 212KB by miklos szeredi
51 posts in 241KB by adrian bunk
40 posts in 433KB by johannes stezenbach
32 posts in 129KB by timur tabi
148 posts in 592KB for "[patch] private mounts"
54 posts in 222KB for "[patch][rfc][0/4] infiniband userspace verbs implementation"
50 posts in 344KB for "2.6.12-rc3-mm1"
36 posts in 144KB for "/proc/cpuinfo format - arch dependent!"
29 posts in 114KB for "filesystem transactions api"

These stats generated by mboxstats version 2.8

1. Linux 2.6.12-rc3-mm1 Released

29 Apr 2005 - 7 May 2005 (55 posts) Archive Link: "2.6.12-rc3-mm1"

Topics: Kernel Release Announcement, Modems, Version Control

People: Andrew MortonEd TomlinsonValdis KletnieksAdrian Bunk

Andrew Morton announced Linux 2.6.12-rc3-mm1, saying:

Ed Tomlinson said:

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.

Valdis Kletnieks replied:

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

There was some discussion of the pros and cons of git. At one point Adrian Bunk said:

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

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

In the course of discussion, Andrew revealed a tidbit about how many folks were downloading kernel releases. He said, "2.6.11-mm1.gz and 2.6.11-mm1.bz2 were downloaded from from 1729 unique IP addresses using http and from an additional 321 unique IP addresses using ftp."

2. Linux 2.6.12-rc3-mm2 Released; Andrew Not Considering git For -mm Tree

30 Apr 2005 - 6 May 2005 (51 posts) Archive Link: "2.6.12-rc3-mm2"

Topics: Kernel Release Announcement

People: Andrew MortonJames CloosMauricio Lin

Andrew Morton announced Linux 2.6.12-rc3-mm2, saying it contained "various fixes" against -mm1.

In the course of discussion, Mauricio Lin posted a patch against the stable tree; and Andrew said, "Please don't generate patches for the mainline kernel against the -stable tree. is ancient - we've added 22MB of diff since then."

Elsewhere, James Cloos asked, "Apologies if this has already been asked and I missed it, but do you expect to transition to exporting your working tree via git, now that licensing concerns are not part of the equation?" Andrew replied:

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.

3. JFS Migrates To git; Developers Consider git Work-Flow

4 May 2005 - 6 May 2005 (7 posts) Archive Link: "[git pull] jfs update"

Topics: FS: JFS

People: Dave KleikampJeff GarzikLinus Torvalds

Dave Kleikamp took a stab at converting his JFS development into a git repository. He said:

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


Linus Torvalds adjusted his scripts to be able to handle a 'HEAD-for-linus' instead of just a 'HEAD', then pulled Dave's changes and added them to his own tree.

Jeff Garzik remarked, "FWIW I'm definitely interested in some sort of pull mechanism where I can say "pull from foo://.../libata-2.6.git/HEAD-for-linus" also. With my netdev-2.6 queue, and given git's intrinsic abilities, I am planning to keep all ~30 or so mini-branches in a single git tree. When I am ready to push some upstream, I can do a HEAD-for-linus merge tree, that merges selected branches." Linus replied:

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.

4. sg3_utils Version 1.14 Released

6 May 2005 - 9 May 2005 (4 posts) Archive Link: "[Announce] sg3_utils-1.14 available"

Topics: Disks: SCSI, Ioctls

People: Douglas Gilbert

Douglas Gilbert said:

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):

For an overview of sg3_utils see this page:

The sg_dd utility has its own page at:

A changelog can be found at:

5. Computone Intelliport Multiport Maintainership

6 May 2005 (1 post) Archive Link: "[2.6 patch] update Computone MAINTAINERS entry"


People: Adrian BunkMichael H. Warfield

Adrian Bunk posted a patch updating the MAINTAINERS file, to clarify that the Computone Intelliport Multiport card was not orphaned as listed, but was still maintained by Michael H. Warfield. Adrian's patch also removed a defunct mailing list address from that entry.

6. sdparm Version 0.91 Released

6 May 2005 (1 post) Archive Link: "[ANNOUNCE] sdparm 0.91"

Topics: Disks: IDE, Disks: SCSI

People: Douglas GilbertJeff Garzik

Douglas Gilbert said:

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:

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]

7. Linux 2.6.12-rc4 Released

6 May 2005 - 10 May 2005 (8 posts) Archive Link: "Linux v2.6.12-rc4"

Topics: Kernel Release Announcement, Spam, User-Mode Linux

People: Linus Torvalds

Linus Torvalds announced Linux 2.6.12-rc4, saying:

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 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.

Coywolf Qi Hunt posted a link to an LXRed 2.6.12-rc4 ( page.

8. yaird Version 0.0.7 Released

8 May 2005 (1 post) Archive Link: "[ANNOUNCE] yaird 0.0.7, a mkinitrd based on hotplug concepts"

Topics: Advanced Encryption Standard, FS: NFS, Hot-Plugging

People: Erik van Konijnenburg

Erik van Konijnenburg said:

Version 0.0.7 of yaird is now available at:

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:

Summary of user visible changes:

On top of the todo list are now:

9. New Automatic Kernel Tunables (AKT) Project Begun

10 May 2005 (2 posts) Archive Link: "[ANNOUNCE] Automatic Kernel Tunables"

Topics: Backward Compatibility, FS: procfs, FS: sysfs, Ottawa Linux Symposium

People: Derbey NadiaJoel Schopp

Derbey Nadia said:

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 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.

Joel Schopp replied, "You might be interested in the work Jacob Moilanen has been doing with genetic algorithm tuning of I/O and CPU schedulers. Google will probably turn up some discussion on this. Also, he is scheduled to give a presentation and paper on this topic at the Ottawa Linux Symposium in July."

10. Linux Released

11 May 2005 (4 posts) Archive Link: "Linux"

Topics: FS: sysfs, I2C, Version Control

People: Greg KHMichal SchmidtChris WrightJean Delvare

Greg KH announced Linux, saying:

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

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 and, as it is small enough to do so.

One of the fixes in this release was an I2C SysFS file permission fix from Jean Delvare, and Michal Schmidt asked, "This was already in, wasn't it?" Chris Wright replied, "Yes. There was a mixup, and the msdos partitions patch got mixed with this one (in So that whole cset was backed out, and this fix was reapplied in"

11. Linux 2.4.31-pre2 Released

12 May 2005 (1 post) Archive Link: "Linux 2.4.31-pre2"

People: Marcelo Tosatti

Marcelo Tosatti announced Linux 2.4.31-pre2, saying:

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.

12. libata Development Migrates From BitKeeper To git

12 May 2005 (2 posts) Archive Link: "Experimental git repositories available for SATA"

Topics: Ioctls, Serial ATA, Version Control

People: Jeff Garzik

Jeff Garzik said:

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://

The new libata-dev repository is libata-dev.git, available at rsync://

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.







Sharon And Joy

Kernel Traffic is grateful to be developed on a computer donated by Professor Greg Benson and Professor Allan Cruse in the Department of Computer Science at the University of San Francisco. This is the same department that invented FlashMob Computing. Kernel Traffic is hosted by the generous folks at All pages on this site are copyright their original authors, and distributed under the terms of the GNU General Public License version 2.0.