What are the various kernel trees for ?
Trees are collections of patches which are generally focussed on addressing a particular need or interest. They help the linux development process in by providing 'places' for work to be developed, and eventually promoted from tree to tree, progressing towards eventual inclusion in mainline.
2.6.X and 2.6.X-rcY
- Maintainer: Linus Torvalds
Goal is to release a new kernel every 8-12 weeks. Once release 2.6.X is released, 2.6.X+1 is opened for 2 weeks, and patches are merged, often from -mm and other maintainer trees, but also from LKML directly. After the 2 week 'open-season', -rc1 is released, which begins the slow freeze from 'slushy', and hardening slowly as -rc2, and successors are released, as Linus sees fit. These are also called current, and mainline Once new releases are made, other trees are re-based against the new release.
-stable ie 2.6.x.y
- Maintainer: Greg Kroah-Hartman This tree gets bug-fixes after 2.6.x is released. Patches must be:
- small - less than 100 lines
- already in current (or equivalent form)
- fixes actual, known, bug
submitted to email@example.com
- Maintainer: Adrian Bunk This tree operates identically to -stable, except its 1 version older. This started with 2.6.16, it may also refer to 2.6.17 once 2.6.18 is released, and 2.6.18.y is reopened as -stable.
- Maintainer: Andrew Morton.
The main staging/integration tree for new features and changes that are being considered for merging into the current kernel tree maintained by Linus.
- typically has 1000-1900 patches, packaged in a single, large, compressed diff.
- provides an easy way to get all the work, and is intended to expose them to much wider testing, on many platforms, than the submitters can cajole others to try.
- patches which survive this testing/integration are eventually moved into mainline, and dropped from -mm
- patches which have problems may be dropped if insufficient progress is made to correct them, but which are often re-added later.
- generally excludes work that has another home tree, until its formally submitted for inclusion into mainline.
- new drivers tend to spend less time here than patches to the kernel itself, or subsystems.
- Maintainer: Con Kolivas.
- A stable 2.6 based patchset with a focus on performance tweaks to the scheduler and vm, with specific tuning for the desktop to improve system responsiveness. With the release of kernel 2.6.22-ck, Con Kolivas has discontinued this branch.
- Maintainer: Ingo Molnar. Realtime-preempt is a set of patches for the latest version of the Linux kernel. They bring the pre-emption capability to the next level. It's goal is to make the full fledged Linux kernel have as close to real-time response as possible. (As a warning, though, the realtime preempt patches are under going heavy development and have been for some times. It's not unusual for Ingo to update the realtime-preempt patch several times a day, or even within hours of each other. ) The -rt tree has been the nursery for several large feature sets, which have matured there, and have since been added to mainline. Notable amongst them are:
- mutexes - after maturing here, mutexes went rapidly through -mm, and into current (at 2.6.17-rc? ??)
- lockdep - locking dependency validator (when?)
- genirq - generic irq framework (when?)
2.5 kernel (historical)
- Maintainer: Dave Jones. Forward ports of 2.4 bugfixes to 2.5 series, plus some other bits. (a slightly less bloody bleeding edge)
- Maintainer: Andrew Morton. Fancy new features and fixes with a focus on VM hacks.
2.4 kernel (historical)
- Maintainer: Alan Cox. Ultra-stable tree for 2.4 series with fixes (security, functionality) for the last stable version. Some of the fixes have already been merged in Linus's tree (the 'official' development tree - at kernel.org), while some others are pending.
- Maintainer: Andrea Arcangeli. VM updates, a multitude of fixes and various improvements from Andrea. The VM from this tree was added into mainline for the 2.4.10 kernel.
- For data center or carrier grade linux, tuning especially for large machines and high database performance.
- Maintainer: Rik van Riel. Rmap has a reverse mapping from page frames to virtual mappings mostly in order to make a more predictable VM, to get rid of some worst case VM behaviours and smooth things out. The reverse mappings provide infrastructure to make a more flexible VM possible ... which means that VM strategies in -rmap often change. The core work in this tree was merged into linux 2.5
You can also browse the available git trees here: http://www.kernel.org/git/