Kprobes (Kernel dynamic probes) is a lightweight mechanism for kernel modules to insert probes into a running kernel, without the need to modify the underlying source. The probe handlers can then be coded to log relevent data at the probe point. More information on kprobes can be found at:

http://www-124.ibm.com/developerworks/oss/linux/projects/kprobes/

Jprobes (or jumper probes) is a small infrastructure to access function arguments. It can be used by defining a small stub with the same template as the routine in kernel, within which the required parameters can be logged.

Personally, I much rather go the way we have gone, because I don't care about module versioning nearly as much as I care about bug-report versioning. And if I hear about a bug with 2.6.10-rc1, I want to know that it really is at _least_ 2.6.10-rc1, if you see what I mean..

Now, personally, I'd actually like to know the exact top-of-tree changeset, so I've considered having something that saves that one away, but then we'd need to do something about non-BK users (make the nightly snapshots squirrell it away somewhere too). That would solve both the module versioning _and_ the bug-report issue.

So if somebody comes up with a build script that generates that kind of extra-version automatically, I'm more receptive. But I don't want to muck with the version manually in a way that I think is the wrong way around..

That's what I had in mind. But it should also check if the top-of-tree is already tagged, and not do anything for that. And it should also hopefully have a CVS/Subversion equivalent, just so that people don't feel left out.

I would _suggest_ just exporting the whole top-of-tree tag to some /sys/kernel/version file (for full bug-reports), but in addition also maybe have a small hash of it (just a few characters of noise) in "uname", to make module versioning work.

So "uname -r" might print out "2.6.9-a$Uv", but then a

        cat /sys/kernel/version/*

would print out something like

        "kernel" file:
                v2.6.9-a$Uv
        "bk-key" file:
                torvalds@ppc970.osdl.org|ChangeSet|20041021004441|21737
        "date" file:
                Wed Oct 20 22:29:23 PDT 2004

or something (one value per file as usual)

The nightly snapshots have been exporting this info since Day One, based on your request ;-)

<snapshot>.key contains this info, e.g. http://www.kernel.org/pub/linux/kernel/v2.6/snapshots/patch-2.6.9-bk1.key is T.O.T. for http://www.kernel.org/pub/linux/kernel/v2.6/snapshots/patch-2.6.9-bk1.bz2

Yes. But that doesn't help the people who actually use the native BK trees themselves, or the people who use the CVS exports. That was what Ben was complaining about.

We already have the concept of "localversion*" files that get appended to the build. So the only thing that would be needed is some Makefile magic to create a "localversion-bk-version" file if the top-of-tree isn't tagged, and we'd get some unique ID for native BK users too.

ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.9/2.6.9-mm1/

• Lots of new patches.

• Status of as-yet-unmerged things:

  • sysfs backing store: after six months, still under discussion.
  • ext3 reservations code: it was ready to go, but then I got a bunch more patches. Lots of testing is needed here to make 2.6.10.
  • ext3 resize code: ready to go, but it depends on the reservation code so I may end up swizzling the patch series.
  • kexec and crashdump: this all allegedly works, but I want to *see* it work first.
  • perfctr: mikpe is still working on this.
  • preempt-smp and all the associated low-latency fixes: I haven't really thought about it and haven't looked at the patches yet. Hopefully 2.6.10 material.
  • cachefs: probably 2.6.10 material, but I'd like to be convinced that we actually need this in the kernel. Not many people use AFS (sorry) and it's a ton of new code. Getting it working for NFS would be a winner.
  • cpusets: ready to go, but the current plan is to rework the actual pinning mechanism to use scheduler domains rather than cpus_allowed, then to look at wiring it up via the CKRM interface. So I'm sitting on this.
  • reiser4: not sure, really. The namespace extensions were disabled, although all the code for that is still present. Linus's filesystem criterion used to be "once lots of people are using it, preferably when vendors are shipping it". That's a bit of a chicken and egg thing though. Needs more discussion.
  • md updates: these are blocked by a minor bunfight over one of Neil's procfs innovations. He's reworking the patches so we can defer that decision.

No distro using reiserfs V3 as the default is going to keep doing so once reiser4 meets their stability requirements. Reiserfs is used by a lot of people, and reiser4 obsoletes it, and the users know that. None of the distros have expressed any intent of staying on V3, and they'd be silly to do it. Many of them have expressed a desire to use reiser4. Next year, indications are that reiser4 usage by distros as their default will exceed that which is today possessed by V3. The higher performance of V4 is going to increase our market share.

I would like to encourage its inclusion as an experimental filesystem BEFORE vendors ship it. I think first putting experimental stuff in the kernels used by hackers makes sense. I think it creates more of a community.

I'd like to point out that there is a lot of stuff in the kernel that is a lot less stable than reiser4.

That said, inclusion in -mm found some bugs, and we are still testing one of the fixes which was a bit deep. I want to finish that testing (not more than 7 days) and send you all fixes before asking for inclusion.

Also, Hellwig made a valid point about getting rid of some macros that reduce readability (I also hate code that prevents editors finding called functions), and zam is working on fixing that.

Lindows is planning on shipping with reiser4 in its next release. I would very much like to see our inclusion before that.

This is a forward port to 2.6 CVS of the lowmem_reserve VM feature in the 2.4 kernel.

http://www.kernel.org/pub/linux/kernel/people/andrea/patches/v2.6/2.6.9/lowmem_reserve-1

Lack of this feature might explain out of memory related killing or deadlocks hit on >2G boxes. so if anybody is having trouble with oom conditions this is a patch to try.

this is only slightly tested but works for me so far.

This is the first of a series of oom related fix I'm going to do and test within the next weeks to attempt to cure various oom regressions in 2.6 (deadlocks turned into crazy early oom kills and the like).

After having an off line review of the SCO claims pertaining to the identified code with Linus, It is clear the SCO has been making claims which are untrue and may have potentially engaged in slander of title, libel, tortorious interference, inteference with partner relations, and intentional inflcition of emotional distress against Linus Torvalds and Linux. Linus has peformed adequate due diligence and acted in good faith with regard to the acceptance of code from IBM and others based on the physical evidence in his possession, and I would testify to this in a court of law if asked as a qualified expert witness on behalf of Linus and Linux.

SCO's claims that some code may have been taken by IBM have nothing whatsoever to do with Linux until as such time they can produce credible evidence to the contrary. Despite numerous requests, visits to their facility, and meetings with them, their disclosure of only a handful of slides and contracts does not constitute corroborating physical evidence that Linus Torvalds tooks their intellectual property and used it in Linux. They are simply unable to produce concrete evidence that identifies the code in question to a degree that refutes the physical evidence pertaining to Linus' due diligence. If IBM's submissions were based in part on intellectual property taken from SCO, then IBM incurs this liability. It is clear at this point Linus acted in good faith in all of his dealings.

Linus Torvalds (and myself) are entitled to apolgies from GrokLaw, and SCO regarding their false and misleading claims Linus missappropriated trade secrets or infringed their copyrights and that I was involved in a scheme with SCO to further their false, misleading, and libelous allegations. Groklaw has also posted numerous emails and comments attributed to me which I did not author which libel Linus and myself, and were designed to create and perpetuate animosity in the Linux Community.

I thank Linus Torvalds for being a true friend and working with me to resolve these issues, despite all the heat and mud flying around.

ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.10-rc1/2.6.10-rc1-mm1/

• Nothing really major here - just lots of minor things spread all over the place.
• I actually managed to get most of the "external BK trees" included. A lot of them have been pretty flakey lately (hint).
• This kernel is probably pretty crappy - there is a _lot_ of stuff happening and the quality of the patches which I am receiving seems to be gradually dropping off.