Kernel Traffic
Latest | Archives | People | Topics
Latest | Archives | People | Topics
Latest | Archives | People | Topics
Home | News | RSS Feeds | Mailing Lists | Authors Info | Mirrors | Stalled Traffic

Kernel Traffic #156 For 4 Mar 2001

By Zack Brown

Table Of Contents


Mailing List Stats For This Week

We looked at 1726 posts in 7494K.

There were 505 different contributors. 275 posted more than once. 200 posted last week too.

The top posters of the week were:

1. Developers Impressed By Changelog; Developer Conflict

13 Feb 2002 - 27 Feb 2002 (162 posts) Archive Link: "linux-2.5.5-pre1"

Topics: Disks: IDE, FS: ReiserFS, Kernel Release Announcement, Version Control

People: Bert HubertLinus TorvaldsRik van RielAndre HedrickJens AxboeMartin Dalecki

Linus Torvalds announced 2.5.5-pre1, and several folks were stunned by the huge changelog. Bert Hubert asked, "Did you always merge this many patches, or does it just look like more using this very nice changelog format? Anyhow, I'm impressed about the amount of work accepted in such a short time." Linus replied:

It looks like more because of the changelog format.

The old changelogs were one-liners, and didn't mention small patches at all (ie the entries like "Remove warning in /proc inode conversions" would not even have made it into the changelog before).

Also, I used to combine entries from the same person, so the eight patches for reiserfs would have been one entry ("reiserfs update"), and the 20 entries from Jeff would likewise have been just one entry ("update network drivers").

That said, this week I've basically spent _only_ on making sure I work well with BitKeeper (so far so good), so I have spent more time than I normally do on merging. So yes, it's actually more merging too. That will calm down eventually.

(The happy news is that I expected to be slowed down by BK for a while, and that hasn't really happened. Some things take more effort now, but to offset that some other stuff is _much_ easier, so..)

An odd exchange between Linus and Andre Hedrick occurred when Martin Dalecki wanted to make some changes to Andre's code. Andre argued that Martin's changes completely broke the driver. Rik van Riel asked Martin directly, "if you are able to make Linux work with 48-bit IDE stuff so Linux is able to talk to drives larger than 137 GB. If you're not, please stop pissing off Andre and work together with him." Jens Axboe and Linus pointed out that 2.5 already supported 48-bit LBA addressing. Linus added:

quite frankly, it's not Martin who cannot work with Andre, it's Andre who so far has shown himself _totally_ unable to work with anybody at all.

Whenever somebody comes and even tries to do trivial and obviously correct cleanups that do not actually change any semantics at all, Andre stands out and shouts bloody murder from the rooftops, completely ignoring the fact that he hasn't even looked at the patches.

All the crap Andre has shouted about "IDE mess" and "timing changes" is total and utter CRAP. None of the patches I've seen has changed _anything_ but cleanups, or removed _any_ features.

Guys, you need to realize that Martin is NOT the bad guy here. The problem is not Martin, the problem is that Andre cannot take any level or criticism, and in the five years or so that he has been maintainer I have yet to see a _single_ person who has been able to work together with him (as opposed to some people who have been able to maintain their own subdrivers _despite_ him).

Andre, your threats about not wanting to maintain 2.5.x are just a symptom of this inability to accept the fact that other people actually do know what they are doing, even if what they are doing is only cleanups with no semantic changes.

Rik, _look_ at the patches, instead of just taking Andre's word for it.

Andre replied:

Obvious you have a bug up the backside, so I am totally hands off until you and Martin are done. See you back at 2.5.10. I will not comment on the changes because you want something and I do not have the timetable to deliver and you are upset.

I am more concerned with the stablity of the core of ATA/ATAPI and next in queue was to address the entire ATAPI data-phases issues that appear to have some problems.

It is clear you want a cosmetic change and I am not ready to make one.

Therefore I will be patient and wait for you get the facelift you want and then see what needs to be salvaged afterwards.

Linus replied that he did indeed have a bug up the backside. He said:

What really bugs me about this is that while normally you're hard to communicate with, this time you have actively _lied_ about the patches on IRC and in email about how they will cause IDE corruption etc due to timing changes.

No such timing changes existed, and whenever you were asked about what was actually actively _wrong_ with the patches, you didn't reply.

There's a difference between being difficult to work with and being actively dishonest, and you crossed that line.

Andre replied:



Lets both grow up!

Linus said:

I repeat, as I did in a private to-you-only email before: every _single_ complain you have had about the patches I've seen has been 100% bogus.

The patch was called "IDE cleanup", and cleanup it was. Nothing but. The timings didn't change, although the stupid (twice duplicated) functions that "calculated" them were removed and replaces with one boot-time calculation.

Martin not only had "cleanup" in the subject line, but actually explained all the changes, including the timing change. The comments at the top of the patch mail said (on that particular change, which seems to have been your favourite target), typos and all:

3. Replace the functionally totally equal system_bus_block() and ide_system_bus_speed() functions with one simple global variable: system_bus_speed. This saves quite a significatn amount of code. Unfortunately this is the part, which is makeing this patch to appear bigger then it really is...

and the patch itself certainly agrees with what Martin claimed.

Your ranting, both on linux-kernel and on the IRC channels, has been totally bogus, as if you didn't read either the explanation _or_ the actual patch itself. And pointing this out multiple times doesn't seem to have made any difference.

Andre replied, "I'm sure you have good reasons for feeling the way you do and beating up on me. I'm often misunderstood because of the way I phrase things. I have no hard feelings, just wish you and I could find a middle ground that worked again."

2. Lucent WinModem Driver Still Proprietary

20 Feb 2002 - 21 Feb 2002 (6 posts) Archive Link: "Lucent WinModem"

Topics: Modems

People: Alan CoxChristoph RohlandWilliam Stearns

Elieser Leão asked a question about using his WinModem under Linux. The driver didn't seem to work for him. William Stearns pointed him to, and Alan Cox remarked, "Ask the binary only driver provider. This list is about free software, and nobody else but the driver vendor can really help you." Nadav Har'El replied that Lucent's driver had been open source for awhile, Christoph Rohland and Todd M. Roy pointed out that the driver "source" contained the binary-only ltmdmobj.o file. As Christoph put it, "The rest is a wrapper for this binary only driver." End of thread.

3. Status Of AIC7XXX In 2.5 And 2.4

20 Feb 2002 - 21 Feb 2002 (7 posts) Archive Link: "AIC7XXX 6.2.5 driver"

People: Jens AxboeAlan CoxJustin T. Gibbs

Carlo Scarfoglio asked if AIC7XXX 6.2.5 would be included in 2.5 or 2.4 any time soon, and Jens Axboe suggested, "You should ask Justin whether he has submitted it for inclusion or not. I offered to port to 2.5 at least, but heard nothing." Alan Cox added, "I was sent a patch for it which included some scsi changes, broke support for the CMD ide controllers and didn't apply in the aic7xxx area. So I threw it in /dev/null." However, Justin T. Gibbs, the author of the patch, pointed out that when he'd sent the patch to Alan, the only reply he got back was "Thanks!" He added, "I'll take that to indicate a toss to /dev/null in the future. 8-)" He asked which version he should generate patches for, and Alan said 2.4.18-rc; they also went into some technical details of what the patch should do.

4. BitKeeper Kernel Hacking HOWTO

21 Feb 2002 - 26 Feb 2002 (12 posts) Archive Link: "BK Kernel Hacking HOWTO"

Topics: Version Control, Virtual Memory

People: Jeff GarzikGeert UytterhoevenAndreas DilgerLarry McVoyDave Jones

Jeff Garzik posted some documentation on using BitKeeper for kernel hacking:

Doing the BK Thing, Penguin-Style

This set of notes is intended mainly for kernel developers, occasional or full-time, but sysadmins and power users may find parts of it useful as well. It assumes at least a basic familiarity with CVS, both at a user level (use on the cmd line) and at a higher level (client-server model). Due to the author's background, an operation may be described in terms of CVS, or in terms of how that operation differs from CVS.

This is -not- intended to be BitKeeper documentation. Always run "bk help <command>" or in X "bk helptool <command>" for reference documentation.

BitKeeper Concepts

In the true nature of the Internet itself, BitKeeper is a distributed system. When applied to revision control, this means doing away with client-server, and changing to a parent-child model... essentially peer-to-peer. On the developer's end, this also represents a fundamental disruption in the standard workflow of changes, commits, and merges. You will need to take a few minutes to think about how to best work under BitKeeper, and re-optimize things a bit. In some sense it is a bit radical, because it might described as tossing changes out into a maelstrom and having them them magically land at the right destination... but I'm getting ahead of myself.

Let's start with this progression:
Each BitKeeper source tree on disk is a repository unto itself.
Each repository has a parent.
Each repository contains a set of a changsets ("csets").
Each cset is one or more changed files, bundled together.

Each tree is a repository, so all changes are checked into the local tree. When a change is checked in, all modified files are grouped into a logical unit, the changeset. Internally, BK links these changesets in a tree, representing various converging and diverging lines of development. These changesets are the bread and butter of the BK system.

After the concept of changesets, the next thing you need to get used to having multiple copies of source trees lying around. This -really- takes some getting used to, for some people. Separate source trees are the means in BitKeeper by which you delineate parallel lines of development, both minor and major. What would be branches in CVS become separate source trees, or "clones" in BitKeeper [heh, or Star Wars] terminology.

Clones and changesets are the tools from which most of the power of BitKeeper is derived. As mentioned earlier, each clone has a parent, the tree used as the source when the new clone was created. In a CVS-like setup, the parent would be a remote server on the Internet, and the child is your local clone of that tree.

Once you have established a common baseline between two source trees -- a common parent -- then you can merge changesets between those two trees with ease. Merging changes into a tree is called a "pull", and is analagous to 'cvs update'. A pull downloads all the changesets in the remote tree you do not have, and merges them. Sending changes in one tree to another tree is called a "push". Push sends all changes in the local tree the remote does not yet have, and merges them.

From these concepts come some initial command examples:

  1. bk clone -q linus-2.5
    Download a 2.5 stock kernel tree, naming it "linus-2.5" in the local dir. The "-q" disables listing every single file as it is downloaded.
  2. bk clone -ql linus-2.5 alpha-2.5
    Create a separate source tree for the Alpha AXP architecture. The "-l" uses hard links instead of copying data, since both trees are on the local disk. You can also replace the above with "bk lclone -q ..."

    You only clone a tree -once-. After cloning the tree lives a long time on disk, being updating by pushes and pulls.

  3. cd alpha-2.5 ; bk pull
    Download changes in "alpha-2.5" repository which are not present in the local repository, and merge them into the source tree.
  4. bk -r co -q
    Because every tree is a repository, files must be checked out before they will be in their standard places in the source tree.
  5. bk vi fs/inode.c                                # example change...
    bk citool                                       # checkin, using X tool
    bk push bk://       # upload change

    Typical example of a BK sequence that would replace the analagous CVS situation,

    vi fs/inode.c
    cvs commit

  6. As this is just supposed to be a quick BK intro, for more in-depth tutorials, live working demos, and docs, see

BK and Kernel Development Workflow

Currently the latest 2.5 tree is available via "bk clone $URL" and "bk pull $URL" at This should change in a few weeks to a URL.

A big part of using BitKeeper is organizing the various trees you have on your local disk, and organizing the flow of changes among those trees, and remote trees. If one were to graph the relationships between a desired BK setup, you are likely to see a few-many-few graph, like this:

         /    |      |
        /     |      |
vm-hacks  bugfixes  filesys   personal-hacks
      \       |      |          /
       \      |      |         /
        \     |      |        /

Since a "bk push" sends all changes not in the target tree, and since a "bk pull" receives all changes not in the source tree, you want to make sure you are only pushing specific changes to the desired tree, not all changes from "peer parent" trees. For example, pushing a change from the testing-and-validation tree would probably be a bad idea, because it will push all changes from vm-hacks, bugfixes, filesys, and personal-hacks trees into the target tree.

One would typically work on only one "theme" at a time, either vm-hacks or bugfixes or filesys, keeping those changes isolated in their own tree during development, and only merge the isolated with other changes when going upstream (to Linus or other maintainers) or downstream (to your "union" trees, like testing-and-validation above).

It should be noted that some of this separation is not just recommended practice, it's actually [for now] -enforced- by BitKeeper. BitKeeper requires that changesets maintain a certain order, which is the reason that "bk push" sends all local changesets the remote doesn't have. This separation may look like a lot of wasted disk space at first, but it helps when two unrelated changes may "pollute" the same area of code, or don't follow the same pace of development, or any other of the standard reasons why one creates a development branch.

Small development branches (clones) will appear and disappear:

-------- A --------- B --------- C --------- D -------
          \                                 /
           -----short-term devel branch-----

While long-term branches will parallel a tree (or trees), with period merge points. In this first example, we pull from a tree (pulls, "\") periodically, such a what occurs when tracking changes in a vendor tree, never pushing changes back up the line:

-------- A --------- B --------- C --------- D -------
          \                       \           \
           ----long-term devel branch-----------------

And then a more common case in Linux kernel development, a long term branch with periodic merges back into the tree (pushes, "/index.html"):

-------- A --------- B --------- C --------- D -------
          \                       \         / \
           ----long-term devel branch-----------------

Submitting Changes to Linus

There's a bit of an art, or style, of submitting changes to Linus. Since Linus's tree is now (you might say) fully integrated into the distributed BitKeeper system, there are several prerequisites to properly submitting a BitKeeper change. All these prereq's are just general cleanliness of BK usage, so as people become experts at BK, feel free to optimize this process further (assuming Linus agrees, of course).

  1. Make sure your tree was originally cloned from the linux-2.5 tree created by Linus. If your tree does not have this as its ancestor, it is impossible to reliably exchanges changesets.
  2. Pay attention to your commit text. The commit message that accompanies each changeset you submit will live on forever in history, and is used by Linus to accurately summarize the changes in each pre-patch. Remember that there is no context, so

    "fix for new scheduler changes"

    would be too vague, but

    "fix mips64 arch for new scheduler switch_to(), TIF_xxx semantics"

    would be much better.

    You can and should use the command "bk comment -C<rev>" to update the commit text, and improve it after the fact. This is very useful for development: poor, quick descriptions during development, which get cleaned up using "bk comment" before issuing the "bk push" to submit the changes.

  3. Include an Internet-available URL for Linus to pull from, such as

    Pull from:

  4. Include a summary and "diffstat -p1" of each changeset that will be downloaded, when Linus issues a "bk pull". The author auto-generates these summaries using "bk push -nl <parent> 2>&1", to obtain a listing of all the pending-to-send changesets, and their commit messages.

    It is important to show Linus what he will be downloading when he issues a "bk pull", to reduce the time required to sift the changes once they are downloaded to Linus's local machine.

    IMPORTANT NOTE: One of the features of BK is that your repository does not have to be up to date, in order for Linus to receive your changes. It is considered a courtesy to keep your repository fairly recent, to lessen any potential merge work Linus may need to do.

  5. Split up your changes. Each maintainer<->Linus situation is likely to be slightly different here, so take this just as general advice. The author splits up changes according to "themes" when merging with Linus. Simultaneous pushes from local development to goes special trees which exist solely to house changes "queued" for Linus. Example of the trees:

    net-drivers-2.5 -- on-going net driver maintenance
    vm-2.5 -- VM-related changes
    fs-2.5 -- filesystem-related changes

    Linus then has much more freedom for pulling changes. He could (for example) issue a "bk pull" on vm-2.5 and fs-2.5 trees, to merge their changes, but hold off net-drivers-2.5 because of a change that needs more discussion.

    Other maintainers may find that a single linus-pull-from tree is adequate for passing BK changesets to him.

Frequently Answered Questions

  1. How do I change the e-mail address shown in the changelog?
    A. When you run "bk citool" or "bk commit", set environment variables BK_USER and BK_HOST to the desired username and host/domain name.
  2. How do I use tags / get a diff between two kernel versions?

    A. Pass the tags Linus uses to 'bk export'.

    ChangeSets are in a forward-progressing order, so it's pretty easy to get a snapshot starting and ending at any two points in time. Linus puts tags on each release and pre-release, so you could use these two examples:

    bk export -tpatch -hdu -rv2.5.4,v2.5.5 | less
    # creates patch-2.5.5 essentially
    bk export -tpatch -du -rv2.5.5-pre1,v2.5.5 | less
    # changes from pre1 to final

    A tag is just an alias for a specific changeset... and since changesets are ordered, a tag is thus a marker for a specific point in time (or specific state of the tree).

Geert Uytterhoeven asked, "what if Linus isn't happy with the changes you made in the for-Him-to-pull tree? How do I back off (part of the changes)?" Andreas Dilger replied:

Well, assuming he tells you that there is a problem, run "bk undo -r <rev>.." to remove the patchset that he doesn't like (in theory). If there have been a large number of changes after <rev> then they are all removed (there is no way to remove only a single CSET from within the middle of the tree. Then you re-do the changes in a way that Linus likes, and submit a new CSET.

You could also add the fix to the same tree and hope he accepts both CSETs, but I think Linus doesn't want to clutter up his tree with <patch>+<fix> instead of a single <patch> that was correct in the first place.

In some cases, you are probably better off to export the changes in <rev> into a diff, get a new Linus BK tree, and re-apply the patches + fixes and generate a new CSET from that.

Not perfect, but that's life.

Geert asked, "So in case he wants a few csets only, I have to redo my for-Him-to-pull-tree. In which case I don't see any advantages compared to emailing a patch with changeset- and file-specific comments. Especially since setting up a for-Him-to-pull-tree requires setting up a publically accessible BK server." Andreas said:

If you want to just send occasional CSETs to Linus or Dave Jones (which is the category that a large majority of people are in) then you can always send a CSET in the mail instead of having a "pull" tree available. Search the l-k archives for my "bksend" script which formats this nicely.

One of the benefits of using BK over patches, even in this situation, is that if your tree is not exactly the same as Linus' the BK CSET will know what version of the tree it was generated against and will make applying and resolving conflicts a lot easier for Linus.

Larry McVoy also replied to Geert, saying:

You can set up a publically accessible tree here, if you need one, see the Hosting link on our website. You can make your tree publically accessible in multiple ways, with varying levels of security, see "bk help bkd".

The advantage of allowing him to pull is that you won't have the same data in your BK tree twice, which you would have if you sent him diffs and then pulled the diffs from him. This is ESPECIALLY IMPORTANT if you have renames (and creates/deletes are a sort of rename) in your patch.

If the situation is that you've created a scratch tree, specifically for sending stuff to Linus and you aren't going to use it for anything else or build on it, then you can send him regular diffs, and toss the tree once you know he accepted them.

Geert was satisfied.

5. BitKeeper: The Saga Continues

22 Feb 2002 - 23 Feb 2002 (18 posts) Archive Link: "Linux 2.4 bitkeeper repository"

Topics: Hyperthreading, Version Control

People: Christoph HellwigJeff GarzikMarcelo TosattiLarry McVoyRik van RielLinus Torvalds

Christoph Hellwig asked:

the Linux 2.4 repository at is orphaned short after it got created. Ist there any chance we could see continguous checkins for it?

I think it might be a good idea to get it automatically checked in once Marcelo uploads a new (pre-) patch as part of the notification procedure (is this possible, Peter?).

If there is no way to automate it I would volunteer to do the checkins, but for that I'd need write permissions to the repository.

Jeff Garzik replied, "As a temporary measure people can pull from, which is always up-to-date with the latest Marcelo pre-patch, and contains nothing else." Marcelo Tosatti added, "As soon as I have time, I'll learn BK and maintain the repository myself." Larry McVoy added:

A couple of useful resources are:

The last one is Jeff's writeup, very nice.

Also, if you want, one of us can get on IRC while you are walking the demo and answer your questions.

Rik van Riel also said:

I've already promised marcelo to setup some repositories, one with Jeff's marcelo-2.4 tree and a few with patches to merge into 2.4.

Then I'll walk marcelo through the process of merging patches with bitkeeper (or rather, letting bitkeeper take care of that stuff) and generally making marcelo familiar with the important bitkeeper commands and some external scripts.

Larry continued:

The main thing is that you need to watch out for renames in patches. bk import -tpatch handles that, straight patch does not. If you don't catch the renames life will suck because one file will be deleted in your tree but may not be deleted yet in another tree. If someone else is working on the old tree and you pull from them, their updates will go to the deleted file. They are there, but pretty useless if you wanted them in the file with the new name.

We need to tweak stuff so that you can use bk import -temail or something like that and it's a combination of Linus' scripts and the current code. Linus? Scripts?

Linus Torvalds replied:

My scripts are on, although I haven't bothered to clean some of them up that really should be cleaned up (things like email parsing that breaks on some emails due to MIME and/or "^From " in the body etc).

Those tools include all the scripts to make changelogs, apply patches from emails etc.

And they require the recent bitkeeper that can take comments and user information for "bk import -tpatch".

(Yeah, "master" isn't an open machine, but Marcelo, Rik, Jeff etc can all get in on it, if somebody wants to push the tools out somewhere else they can certainly do so).

Elsewhere, in reply to something else, Larry mentioned, "I need to extract Linus' toolkit from him and integrate it into a BK release so you can do those nice patch imports he does. Linus? Can you push your stuff to bitmover, I still don't have a working account on"

6. Status Of NUMA Scheduling In 2.4

22 Feb 2002 - 27 Feb 2002 (19 posts) Archive Link: "NUMA scheduling"

Topics: Big O Notation, Scheduler

People: Mike KravetzIngo Molnar

Mike Kravetz announced:

Below is preliminary patch to implement some form of NUMA scheduling on top of Ingo's K3 scheduler patch for 2.4.17. This is VERY early code and brings up some issues that need to be discussed/explored in more detail. This patch was created to form a basis for discussion, rather than as a solution. The patch was created for the i386 based NUMA system I have access to. It will not work on other architectures. However, the only architecture specific code is a call to initialize some of the NUMA specific scheduling data structures. Therefore, it should be trivial to port.

Here is what the patch does:

Things not addressed in the patch:

A slew of people replied that they'd also been working on a NUMA extension to Ingo Molnar's O(1) scheduler patch, and a bunch of them had a technical discussion of Mike's work.

7. Status Of Promise 20269 Support In 2.4

23 Feb 2002 (5 posts) Archive Link: "Promise 20269 support?"

People: Alan CoxMike FedykRoy Sigurd Karlsbakk

Roy Sigurd Karlsbakk asked when (or if) Promise 20269 support would be added to 2.4; Alan Cox predicted 2.4.19, and Roy asked what was causing the holdup. Alan replied, "Its just a matter of timing. Its been tested a fair bit in -ac now, and is looking very good, but Marcelo is going to delete any submission like that for 2.4.18-rc, and rightfully so." As Mike Fedyk put it, "IIRC there was much controvercy about the ide patches when 2.4.18-pre-early was open, and when the things washed over that time window was closed. Marcello only accepts large changes in 2.4-pre-early, so it was too late..."

8. Microkernel

25 Feb 2002 - 26 Feb 2002 (7 posts) Archive Link: "Monolithic Vs. Microkernel"

Topics: Microkernels: Hurd

People: Larry McVoyAlan CoxHans AdamsDavid LangRik van RielLinus Torvalds

Rakesh Kumar Banka asked if anyone was working on a micro-kernel implementation of Linux, and there were several replies. Larry McVoy said, "Not if they learned from history, they aren't. But the Hurd could use your help, they're a microkernel." Alan Cox corrected him, saying, "There are several Linux on microkernel implementations around, thankfully using something that can really be called a microkernel. With the "we want to run 10,000 copies of Linux on a box" market boom it may well prove to have a practical use one day - as well as the security partitioning one which some people overlook (and paranoid security people often do not mind a small performance hit)." Hans Adams added:

at least two teams work upon it here in Germany


A branch of stable kernels upon L4/Fiasco is maintained at TU Dresden and available at:

Though Mr. Torvalds seems not to be amused about micro kernel aproach, this work is not done in vein due to the inherent technical superiority in certain applications mostly regarding distributed systems including NUMA architectures.

David Lang added, regarding Linus Torvalds' choice of monolithic kernel structure, "it boils down to the fact that Linus believes that a microkernel ends up spending to much of it's time formatting messages for other pieces of itself instead of doing the work you purchased the computer to do." And Rik van Riel put in "You have to remember that the source code for Linux is available. This means we can have all the advantages of modularity at the source level without needing any of the potential disadvantages of modularity at the binary level."







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.