Table Of Contents
|1.||29 Apr 2005 - 7 May 2005||(55 posts)||Linux 2.6.12-rc3-mm1 Released|
|2.||30 Apr 2005 - 6 May 2005||(51 posts)||Linux 2.6.12-rc3-mm2 Released; Andrew Not Considering git For -mm Tree|
|3.||4 May 2005 - 6 May 2005||(7 posts)||JFS Migrates To git; Developers Consider git Work-Flow|
|4.||6 May 2005 - 9 May 2005||(4 posts)||sg3_utils Version 1.14 Released|
|5.||6 May 2005||(1 post)||Computone Intelliport Multiport Maintainership|
|6.||6 May 2005||(1 post)||sdparm Version 0.91 Released|
|7.||6 May 2005 - 10 May 2005||(8 posts)||Linux 2.6.12-rc4 Released|
|8.||8 May 2005||(1 post)||yaird Version 0.0.7 Released|
|9.||10 May 2005||(2 posts)||New Automatic Kernel Tunables (AKT) Project Begun|
|10.||11 May 2005||(4 posts)||Linux 18.104.22.168 Released|
|11.||12 May 2005||(1 post)||Linux 2.4.31-pre2 Released|
|12.||12 May 2005||(2 posts)||libata Development Migrates From BitKeeper To git|
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 Morton, Ed Tomlinson, Valdis Kletnieks, Adrian Bunk
Andrew Morton announced Linux 2.6.12-rc3-mm1, saying:
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.
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:
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 kernel.org 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 Morton, James Cloos, Mauricio 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 22.214.171.124 tree; and Andrew said, "Please don't generate patches for the mainline kernel against the -stable tree. 126.96.36.199 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 Kleikamp, Jeff Garzik, Linus 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): 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
5. Computone Intelliport Multiport Maintainership
6 May 2005 (1 post) Archive Link: "[2.6 patch] update Computone MAINTAINERS entry"
Topics: MAINTAINERS File
People: Adrian Bunk, Michael 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 Gilbert, Jeff 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: 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 
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 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.
Coywolf Qi Hunt posted a link to an LXRed 2.6.12-rc4 (http://sosdg.org/~coywolf/lxr/source/) 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 Nadia, Joel 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:
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:
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.
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.
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 188.8.131.52 Released
11 May 2005 (4 posts) Archive Link: "Linux 184.108.40.206"
Topics: FS: sysfs, I2C, Version Control
People: Greg KH, Michal Schmidt, Chris Wright, Jean Delvare
Greg KH announced Linux 220.127.116.11, saying:
Due to a recently announced security issue with the current kernel, we (the -stable team) are announcing the release of the 18.104.22.168 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 22.214.171.124 and 126.96.36.199, 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 188.8.131.52, wasn't it?" Chris Wright replied, "Yes. There was a mixup, and the msdos partitions patch got mixed with this one (in 184.108.40.206). So that whole cset was backed out, and this fix was reapplied in 220.127.116.11."
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://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.
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 kernel.org. All pages on this site are copyright their original authors, and distributed under the terms of the GNU General Public License version 2.0.