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

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.

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.

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.

"LIAR LIAR PANTS ON FIRE"

Linus,

Lets both grow up!

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.

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 http://linux.bkbits.net/linux-2.5 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 http://gkernel.bkbits.net/alpha-2.5
   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://gkernel@bkbits.net/alpha-2.5       # upload change

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

   vi fs/inode.c
   cvs commit

As this is just supposed to be a quick BK intro, for more in-depth tutorials, live working demos, and docs, see http://www.bitkeeper.com/

BK and Kernel Development Workflow

Currently the latest 2.5 tree is available via "bk clone $URL" and "bk pull $URL" at http://linux.bkbits.net/linux-2.5 This should change in a few weeks to a kernel.org 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:

            linux-2.5
                |
       merge-to-linus-2.5
         /    |      |
        /     |      |
vm-hacks  bugfixes  filesys   personal-hacks
      \       |      |          /
       \      |      |         /
        \     |      |        /
         testing-and-validation

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, "/"):

-------- 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: http://gkernel.bkbits.net/net-drivers-2.5

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

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.

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.

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.

the Linux 2.4 repository at linux.bkbbits.net 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 kernel.org 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.

A couple of useful resources are:

http://www.bitkeeper.com/cvs2bk.html

http://www.bitkeeper.com/Test.html

http://news.linuxprogramming.com/news_story.php3?ltsn=2002-02-21-001-06-DT-HT

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.

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.

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?

My scripts are on master.kernel.org:/home/torvalds/BK/tools, 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).

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:

• Creates 'cpu sets', which are sets of cpus that tasks can be scheduled on. The cpus in these sets should all have something in common such as local memory, a shared cache, etc.
• In general, once a task begins execution on a cpu set, it remains on that cpu set. The load balancing code that exists in the K3 scheduler is used to balance the load among cpus within a set.

• Load balancing also takes place across cpu set boundaries. Load balancing across set boundaries can happen:

  • at exec time. This is an obvious choice since we have just thrown away a tasks address space and are about to create a new one. The exec'ing task is migrated to the least loaded cpu set
  • when a cpu goes idle. At this time we first look for another task to run within the cpu set. If there is no task available within the set, then we attempt to get a task from the most loaded cpu set.
  • at specified intervals when a cpu is idle. In the K3 scheduler, the timer code notices a cpu is idle and looks for more work to do. First it checks other runqueues within the cpu set. If nothing is found, it attempts to get a task from the most loaded cpu set.
  • at specified intervals when a cpu is busy. This is also kicked off via the timer interrupt code. It simply attempts to move tasks from the most loaded cpu sets to the least loaded cpu sets.

  For the most part, cpu set load balancing is invoked in the same places as cpu to cpu load balancing in the K3 scheduler. The only exception is exec time task placement. In the patch, the various forms of cpu set load balancing are behind #defines which can be turned on or off for experimentation.

Things not addressed in the patch:

• Topology discovery. To create cpu sets, a routine numa_sched_init() is called after we know how many cpus there are in the system. Inside numa_sched_init(), there are hard coded values used to indicate the number of cpus per set, and the 'distance' between sets. Obviously, creation of cpu sets would be based on topology information that is not available at this time. In addition, there should be support for (or at least an understanding of) non-symmetric and multi-level topologies.
• Tasks should have a notion of a 'home' cpu set. Short term execution of a task on a remote cpu set should only be done to take advantage of idle cpus. Tasks should only execute for short periods of time on remote cpu sets. Most task execution should occur on the home cpu set. Long term execution on a remote cpu set would involve a full task migration which includes moving/copying the memory associated with the task.
• Partitioning of scheduling data. On a NUMA architecture, data structures should be backed by memory local to the cpus which will be accessing them most frequently. Therefore, things like runqueues and cpu_sets should not be arrays.
• Better determination for what tasks to execute remotely/migrate. The path uses the existing code in load_balance(). Most likely this will be sufficient.

at least two teams work upon it here in Germany

references:

http://os.inf.tu-dresden.de/index.xml.de

http://i30www.ira.uka.de

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

http://os.inf.tu-dresden.de/L4/LinuxOnL4/.

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.