Differences between version 27 and revision by previous author of LinuxKernel2.6.
Other diffs: Previous Major Revision, Previous Revision, or view the Annotated Edit History
| Newer page: | version 27 | Last edited on Saturday, June 18, 2005 12:07:36 pm | by DanielLawson | Revert |
| Older page: | version 25 | Last edited on Thursday, February 17, 2005 1:07:58 pm | by JohnMcPherson | Revert |
@@ -9,11 +9,26 @@
Before a kernel is deemed stable enough for, say, server use, it goes through a long beta testing process. This gets an odd-numbered minor revision number - in this case 2.5. When it's stable enough (no obvious major bug or instabilities) it is feature frozen (after going through a 2.6-test phase, which is where we're at now) and becomes a "stable" kernel. Development does not stop here - there are still going to be bugs and the testers cant possibly test things on every platform and chipset. This requires a lot of work, and as soon as a kernel becomes "stable", the rejected or unstable features from the previous beta cycle are forked again into another tree, and the minor revision is incremented again.
Due to the heavy workload placed on a kernel maintainer ([LinusTorvalds] being the most memorable, but [AlanCox] is another), the maintainers handle one branch each - at the moment Alan is handling the 2.2 "stable" branch, Marcelo Tosatti is in charge of the 2.4 "stable" brach, and Andrew Morton has been handed the 2.6 branch so that Linus can work on 2.7 and beyond. At least for the time being, you can identify a beta kernel by right of it having an odd minor revision, and a stable kernel by an even minor revision.
-The current Linux kernel tree is 2.6.x. As
of this writing
the latest public available patch
is 2.6.8
.
+The current Linux kernel tree is 2.6.x.
+
+!!!2.6 Numbering Scheme.
+
+There has been a bit
of debate over the future of the linux kernel numbering scheme as described above, which has resulted in some significant changes. The "oddnumber" development branch is no longer the default approach. That is to say, there is currently no 2.7 branch, nor are there any plans on releasing one. Instead, all the development is done within the 2.6 tree, although newer risky features are added into a branch of the 2.6 tree, such as the -mm branch. This does __not__ mean that the 2.6.x kernel is an "unstable" kernel, or that running
the latest 2.6.x kernel
is "risky". The kernel team are putting a lot of effort into making sure each release is stable, and the time between
2.6.x releases has increased accordingly.
+
+In order to accomodate urgent patches, a new "-stable" style set of kernels has been released. These are described in the form of 2.6.x.y, where .x is the current kernel, and y is the current patchlevel to said kernel. There are some strict criteria as to what patches are allowed to be incorporated into this branch, such as "must be less than 100 lines of code", "must fix an oops or other critical bug, or a security risk" and "must be a real risk". The 2.6.x.y tree only exists for as long as the 2.6.x kernel is the current one - once 2.6.(x+1) is released, no more additions can be made to 2.6.x.y.
+
+For example, the current (20 March 2005) kernel release is 2.6.11, and the current revision of that is 2.6.11.5. There have been a fairly impressive array of fixes included into these kernels, including oops corrections, driver regression fixes, security fixes, and so on. When 2.6.12 is released, it will automatically pull in any of the fixes included in 2.6.11.y, which haven't already been included.
+
+It's worth pointing out that you don't ever have to use these new kernel revisions. If none of the patches affect your hardware or system in anyway, there's no real reason to upgrade. One of the major benefits to this new scheme is that if a major security vulnerability, or other major failure (such as the 2.4.11 dangling-symlink-eats-your-filesystem bug) occurs before a new kernel is ready to be released, a 2.6.x.y kernel can be released fixing this problem (assuming it's a small fix!). The fix can be pushed out without hurrying the next kernel - something which seems to have contributed in the past to some kernel instability
.
+
+
+!!!New Features
The 2.6 tree adds two features that can lead to signifigant performance gains. The first one is reverse mapping of physical to virtual memory, which provides a better solution for paging as the kernel can now reuse pages allocated for a particular task rather than having to reallocate each time said task requires swap. The second one allows processes to be preempted anywhere in the kernel which reduces the average response time to 1ms, meaning the kernel spends less time idle under pressure, and so visible performance is, under certain circumstances, greatly improved. Other cool things added in the new kernel include the merging of [ALSA], which has finally superceded OSS/Free] as the preferred sound driver for Linux. For those of you unfamiliar with the Advanced Linux Sound Architecture, it beats down OSS in pretty much every respect, as well as adding support for multiple channel muxing on sound cards which support it, and supports a whole lot more chipsets then OSS could ever dream of doing.
+
+Another new feature in the 2.6 kernel was the addition of selectable IO schedulers. These control the way the kernel schedules reads and writes to the disk subsystem. See LinuxIoScheduler for more information
!!!Caveat Emptor
It took kernel 2.4 about 14 patches and three different VM systems before a "stable" stable version. 2.6 has gone through several months of test kernels, but the design methodology still says "release it to primetime and let the users do the testing" (otherwise, no-one would!) Running a beta kernel is not reccomended for any server or otherwise important box. If in doubt, wait six months. It should be fine to run on a workstation until then. There are some cases, however, when a [RAID] or [SCSI] controller isn't supported by the 2.4 series kernels, so if you want to use one of them in a server, your best bet is upgrading (carefully) to 2.6.
