ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.12-rc2/2.6.12-rc2-mm3/

• The anticipatory I/O scheduler has always been fairly useless with SCSI disks which perform tagged command queueing. There's a patch here from Jens which is designed to fix that up by constraining the number of requests which we'll leave pending in the device.

  The depth currently defaults to 1. Tunable in /sys/block/hdX/queue/iosched/queue_depth

  This patch hasn't been performance tested at all yet. If you think it is misbehaving (the usual symptom is processes stuck in D state) then please report it, then boot with `elevator=cfq' or `elevator=deadline' to work around it.

• More CPU scheduler work. I hope someone is testing this stuff.

Here's an attempt at dynamic sched domains aka isolated cpusets

• This functionality is on top of CPUSETs and provides a way to completely isolate any set of CPUs dynamically.
• There is a new cpu_isolated flag that allows users to convert an exclusive cpuset to an isolated one
• The isolated CPUs are part of their own sched domain. This ensures that the rebalance code works within the domain, prevents overhead due to a cpu trying to pull tasks only to find that its cpus_allowed mask does not allow it to be pulled. However it does not kick existing processes off the isolated domain

• There is very little code change in the scheduler sched domain code. Most of it is just splitting up of the arch_init_sched_domains code to be called dynamically instead of only at boot time. It has only one API which takes in the map of all cpus affected and the two new domains to be built

  rebuild_sched_domains(cpumask_t change_map, cpumask_t span1, cpumask_t span2)

There are some things that may/will change

• This has been tested only on x86 [8 way -> 4 way with HT]. Still needs work on other arch's
• I didn't get a chance to see Nick Piggin's RCU sched domains code as yet, but I know there would be changes here because of that...
• This does not support CPU hotplug as yet

• Making a cpuset isolated manipulates its parent cpus_allowed mask. When viewed from userspace this is represented as follows

  [root@llm11 cpusets] cat cpus
  0-3[4-7]

  This indicates that CPUs 4-7 are isolated and is/are part of some child cpuset/s

you know what the subject line means by now, but this release is a bit different from the usual ones, for obvious reasons. It's the first in a _long_ time that I've done without using BK, and it's the first one ever that has been built up completely with "git".

It's available both as a patch (against 2.6.11) and as a tar-ball, and for non-BK users the biggest difference is probably that the ChangeLog format has changed a bit. And it will probably continue to evolve, since I don't have my "release-script" tools set up for the new setup, so this release was done largely manually with some ad-hoc scripting to get the ChangeLog information etc out of git.

For BK users, I hope we can get a BK tree that tracks this set up soon, and it should hopefully not be too disruptive either.

And for the crazy people, the git archive on kernel.org is up and running under /pub/scm/linux/kernel/git/torvalds/linux-2.6.git. For the adventurous of you, the name of the 2.6.12-rc3 release is a very nice and readable:

a2755a80f40e5794ddc20e00f781af9d6320fafb

and eventually I'll try to make sure that I actually accompany all releases with the SHA1 git name of the release signed with a digital signature.

One of the tools I don't have set up yet is the old "shortlog" script, so I did this really hacky conversion. You don't want to know, but let's say that I'm re-aquainting myself with 'sed' after a long time ;). But if some lines look like they got hacked up in the middle, rest assured that that's exactly what happened, and the long log should have the rest ...

A word of warning: in many ways it's easier to work with patches. In particular, if you want to have me merge from your tree, I require a certain amount of cleanliness in the trees I'm pulling from. All of the people who used to use BK to sync are already used to that, but for people who didn't historically use BK this is going to be a learning experience.

The reason patches are easier is that you can start out from a messy tree, and then whittle down the patch to just the part you want to send me, so it doesn't actually matter how messy your original tree is, you can always make the end result look nice.

One of the things a distributed SCM brings with it is that you can't edit history after the fact, which means that if you use git and you've got a messy tree, you can't just "clean it up". You either have to keep your tree clean all the time, or you have to generate a new clean tree (usually by exporting patches from your messy one) and throw the messy ones away periodically.

("throw-away" git trees are actually very very useful).

git is actually even _more_ strict than BK in this respect, since the git model means that everything is based on SHA1 hashes, and you can't edit _anything_. With BK, some people were used to edit the checkin comments after the fact, and you could do that kind of limited cleanup before you asked me to merge. With git, that's all hashed cryptographically and is part of the "name" of the result, so if you want to change the checkin comments, you literally have to throw the old one (and every later checkin that has it as its parents) away, and re-generate the whole chain.

This is very much by design. This is how git (and I) can trust the end result. It is how git can know that if we have a common parent, all the history before that common parent is guaranteed to be the same for both you and me, and git can thus ignore it. But as mentioned, it does mean that git history is set in stone, and the only way to "fix" things is literally to re-create it all.

The main issue is if you want to use git for development and accepting patches from others, you need to be used to not using that git tree to send patches to Linus. To send patches to him, do something like the following:

• export the patches from your git tree
• pick and choose what you want to send off, cleaning up the changelog comments and merging patches that need to be.
• clone the latest copy of Linus's tree.
• apply the patches to that tree.
• make the tree public
• generate an email with the diffs and send that off to lkml and Linus.

Because of all of this, I've found that it is easier to use quilt for day-to-day development and acceptance of patches. Then use git to build up trees for Linus to pull from.

But you might find your workflow is different :)

Yeah, getting Andrew into the picture is a bit different. Previously, with bk, I could just have him pull from my trees, and generate a patch from that. And actually, with git that would work just as well, so if you make your git working trees public, he can pull from them and you're fine.

But with quilt it's different. That's why I make up a big patch which is the sum of my individual patches and put them on a public site. Right now you can see this at:
kernel.org/pub/linux/kernel/people/gregkh-2.6/
The patches in that directory are the "rolled up" ones. The script there is what I use to build these patches, if you want to do something like it.

In the patches/ subdir below that one, is a mirror of my quilt patches directory, series file and all. That way people can still see the individual patches if they want to.

Does this help some? It's all still under flux as to how this all works, try something and go from there :)

Andrew has some work to do before he can regain momentum:

• Which subsystem maintainers will have public git trees?
• Which maintainers will continue to use bk?
• Can Andrew legally use the bk client?
• Can Andrew legally use a bk client which won't go phut at cset 65535?
• How do I do a bk `gcapatch' is there is no Linus bk tree to base it off?
• If none of the above, which maintainers will put up-to-date raw patches in places where Andrew can get at them?

I don't know how all this will pan out. I guess the next -mm won't have many subsystem trees and I'll gradually add them as things get sorted out.

Of course, whatever gets done, I'd selfishly prefer that most (or even all) subsystem maintainers work the same way and adopt the same work practices.

I guess it's too early to think about that, but if one maintainer (hint) were to develop and document a good methodology and toolset, others might quickly follow.

The reason I've not done tags yet is that I haven't decided how to do them.

The git-pasky "just remember the tag name" approach certainly works, but I was literally thinking o fsetting up some signing system, so that a tag doesn't just say "commit 1da177e4c3f41524e886b7f1b8a0c1fc7321cac2 is v2.6.12-rc2", but it would actually give stronger guarantees, ie it would say "Linus says that commit 1da177e4c3f41524e886b7f1b8a0c1fc7321cac2 is his 2.6.12-rc2 release".

That's something fundamentally more powerful, and it's also something that I actually can integrate better into git.

In other words, I actually want to create "tag objects", the same way we have "commit objects". A tag object points to a commit object, but in addition it contains the tag name _and_ the digital signature of whoever created the tag.

Then you just distribute these tag objects along with all the other objects, and fsck-cache can pick them up even without any other knowledge, but normally you'd actually point to them some other way too, ie you could have the ".git/tags/xxx" files have the pointers, but now they are _validated_ pointers.

That was my plan, at least. But I haven't set up any signature generation thing, and this really isn't my area of expertise any more. But my _plan_ literally was to have the tag object look a lot like a commit object, but instead of pointing to the tree and the commit parents, it would point to the commit you are tagging. Somehting like

        commit a2755a80f40e5794ddc20e00f781af9d6320fafb
        tag v2.6.12-rc3
        signer Linus Torvalds

        This is my official original 2.6.12-rc2 release

        -----BEGIN PGP SIGNATURE-----
        ....
        -----END PGP SIGNATURE-----

with a few fixed headers and then a place for free-form commentary, everything signed by the key (and then it ends up being encapsulated as an object with the object type "tag", and SHA1-csummed and compressed, ie it ends up being just another object as far as git is concerned, but now it's an object that tells you about _trust_)

(The "signer" field is just a way to easily figure out which public key to check the signature against, so that you don't have to try them all. Or something. My point being that I know what I want, but because I normally don't actually ever _use_ PGP etc, I don't know the scripts to create these, so I've been punting on it all).

If somebody writes a script to generate the above kind of thing (and tells me how to validate it), I'll do the rest, and start tagging things properly. Oh, and make sure the above sounds sane (ie if somebody has a better idea for how to more easily identify how to find the public key to check against, please speak up).

Btw, in case it wasn't clear, one of the advantages of this is that these objects are really _not_ versioned themselves, and that they are totally independent of the objects that they actually tag.

They spread together with all the other objects, so they fit very well into the whole git infrastructure, but the real commit objects don't have any linkages to the tag and the tag objects themselves don't have any history amongst themselves, so you can create a tag at any (later) time, and it doesn't actually change the commit in any way or affect other tags in any way.

In particular, many different people can tag the same commit, and they don't even need to tage their _own_ commit - you can use this tag objects to show that you trust somebody elses commit. You can also throw the tag objects away, since nothing else depends on them and they have nothing linking to them - so you can make a "one-time" tag object that you can pass off to somebody else, and then delete it, and now it's just a "temporary tag" that tells the recipient _something_ about the commit you tagged, but that doesn't stay around in the archive.

That's important, because I actually want to have the ability for people who want me to pull from their archive to send me a message that says "pull from this archive, and btw, here's the tag that not only tells you which head to merge, but also proves that it was me who created it".

Will we use this? Maybe not. Quite frankly, I think human trust is much more important than automated trust through some technical means, but I think it's good to have the _support_ for this kind of trust mechanism built into the system. And I think it's a good way for distributors etc to say: "this is the source code we used to build the kernel that we released, and we tagged it 'v2.6.11-mm6-crazy-fixes-3.96'".

And if my key gets stolen, I can re-generate all the tags (from my archive of tags that I trust), and sign them with a new key, and revoke the trust of my old key. This is why it's important that tags don't have interdependencies, they are just a one-way "this key trusts that release and calls it xyzzy".

But this is a _feature_.

Other people normally shouldn't be interested in your tags. I think it's a mistake to make everybody care.

So you normally would fetch only tags you _know_ about. For example, one of the reasons we've been _avoiding_ personal tags in teh BK trees is that it just gets really ugly really quickly because they get percolated up to everybody else. That means that in a BK tree, you can't sanely use tags for "private" stuff, like telling somebody else "please sync with this tag".

So having the tag in the object database means that fsck etc will notice these things, and can build up a list of tags you know about. It also means that you can have tag-aware synchronization tools, ie exactly the kind of tools that only grab missing commits can also then be used to select missing tags according to some _private_ understanding of what tags you might want to find..

# This creates the signature.
gpg --clearsign < sign_this > signature

# And this verifies it.
gpg --verify < signature && echo valid

This really doesn't work for me - I do not want to have the gpg header above it, only the signature below. Since I want git to actually understand the tags, but do _not_ want git to have to know about whatever signing method was used, I really want the resulting file to look like

commit ....
tag ...

here goes comment
here goes signature

and no headers.

Whether that can be faked by always forcing SHA1 as the hash, and then just removing the top lines, and re-inserting them when verifying, or whether there is some mode to make gpg not do the header crud at all, I don't know. Which is exactly why I never even got started.

NO.

Guys, I will say this once more: git will not look at the signature.

That means that we don't "strip them off", because dammit, they DO NOT EXIST as far as git is concerned. This is why a tag-file will _always_ start with

commit <commit-sha1>
tag <tag-name>

because that way we can use fsck and validate reachability and have things that want trees (or commits) take tag-files instead, and git will automatically look up the associated tree/commit. And it will do so _without_ having to understand about signing, since signing is for trust between _people_ not for git.

And that is why I from the very beginning tried to make ti very clear that the signature goes at the end. Not at the beginning, not in the middle, and not in a different file. IT GOES AT THE END.

No. It's not "impossible" for git to parse crap. But git won't.

There are two ways you can write programs:

• reliably
• unreliably

and I do the first one. That means that a program I write does something _repeatable_. It does the same thing, regardless of whether a human happened to write "REF:" in the comment section, or anything else.

The thing is, great programs come not out of great coding, but out of great data structures. The whole git philosophy bases itself on getting the data structure right.

And what you are asking for is doing it _wrong_. So in git I don't just parse random free-form text and guess that a line that starts with REF: is a reference to a commit. It has very rigid and well-specified data structures, and that's how you make reliable programs.

I don't care what anybody else does on top of git, but dammit, I'll make sure that the core infrastructure is designed the right way.

And that means that we don't guess, and that we don't parse random ASCII blobs. It means that we have very very fixed formats so that programs can either do the right thing or unambiguously say "that's crap".

I've said it before, and I'll say it again: we have enough crap that calls itself SCM's out there already. I want git to be reliable and _simple_, not a collection of crap that just happens to work.

The setup.S change in this patch should be OK. As it is adding to the existing zero-page and keeping it within one page. I tested it on systems with grub, adding some dummy E820 entries and it worked fine.

However, there is another place that needs to be changed. Boot loaders also calls E820 while booting directly with vmlinux (instead of usual bzImage - which is handled by this patch) and that needs to change to incorporate more E820 entries. But, there we may need more changes, to the boot protocol version and the like. On a side note, looking at the grub source, it seems to have a limit of 50 entries today, which doesn't agree with current 32 entry limit in the kernel. Not sure why grub has this different limit though.

Tested this patch with some more configuration and I did not see any breakage.

• LILO with EDID enabled
• pxeboot

And in the current zero-page, EDID info is at a lower address (before E820MAP). So, there should not be any issues with EDID info. Only field (other than E820) that is changing in zero page is EDDBUF (that comes after E820MAP). The patch changes the reference to EDDBUF inside kernel to new position in zero page. And I don't see EDDBUF being used by boot loader anywhere. So, we should be OK with that change.

here goes Cogito-0.8, my SCMish layer over Linus Torvald's git tree history tracker. This package was formerly called git-pasky, however this release brings big changes. The usage is significantly different, as well as some basic concepts; the history changed again (hopefully the last time?) because of fixing dates of some old commits. The .git/ directory layout changed too.

Upgrading through pull is possible, but rather difficult and requires some intimacy with both git, git-pasky and Cogito. So probably the best way to go is to just get cogito-0.8 tarball at

http://www.kernel.org/pub/software/scm/cogito/

or

ftp://ftp.kernel.org/pub/software/scm/cogito/

build and install it, and do

cg-clone rsync://rsync.kernel.org/pub/scm/cogito/cogito.git

Yes, this is a huge change. No, I don't expect any further changes of similar scale. I think the new interface is significantly simpler _and_ cleaner than the old one.

First for the concept changes. There is no concept of tracking anymore; you just do either cg-pull to just fetch the changes, or cg-update to fetch them as well as merge them to your working tree. Even more significant change is that Cogito does not directly support local branches anymore - git fork is gone, you just go to new directory and do

cg-init ~/path/to/your/original/repository

(or cg-clone, which will try to create a new subdirectory for itself). This now acts as a separate repository, except that it is hardlinked with the original one; therefore you get no additional disk usage. To get new changes to it from the original repository, you have to cg-update origin. If you decide you want to merge back, go to the original repository, add your new one as a branch and pull/update from it.

As for the interface changes, you will probably find out on your own; cg-help should be of some help. All the scripts now start with 'cg-', and you should ignore the 'cg-X*' ones. The non-trivial mapping is:

git addremote -> cg-branch-add
git lsremote -> cg-branch-ls
git patch -> cg-mkpatch
git apply -> cg-patch
git lsobj -> cg-admin-lsobj

Commands that are gone:

git fork
git track

New commands:

cg-clone
cg-update

Of course other changes include various bugfixes, and latest Linus' stuff (although we do not make use of Linus' tags yet).

Note that I don't know how many time will I have for hacking Cogito until the next Sunday/Monday. I hope I will get some time to at least apply bugfixes etc, but I don't know how much more will I be able to do. You would make me a happy man if you could please port your pending patches from git-pasky to Cogito; I promise to apply them and I hope there isn't going to be another so big change in the foreseeable future, which would cause major conflicts for your patches etc.

OpenSSI 1.9.0 is a development release. For a stable release, download OpenSSI 1.2.2 instead. This is the first release based on a 2.6 kernel, 2.6.10 to be precise.

To know more about OpenSSI visit www.openssi.org.

To download and install

http://www.openssi.org/cgi-bin/view?page=docs2/1.9/debian/INSTALL.html

Finally, we now present you with a feature complete version of Umbrella, namely version 0.7.

Followin is the main major changes:

• Implementation of a kernel keyring to handle keys from trusted vendors
• The FSR implementation is replaced and optimized
• Umbrella has been profiled and optimized all over

For instructions on how to try out the Process-Based Access Control and Digitally Signed Binaries in Umbrella, please download the complete 0.7 tarball from SourceForge: http://prdownloads.sourceforge.net/umbrella/umbrella-0.7.tar.bz

Please refer to the README file in the tarball for further instructions.

As always we appreciate any comments, suggestions etc. you may have :-)