Penguin
Note: You are viewing an old revision of this page. View the current version.

The latest stable kernel series. After several months of test versions, 2.6.0 was released on 18 December 2003.

A note on numbering

The Linux kernel has an unusual1? numbering system. The main version number is changed whenever there is a feature added that requires a significant rewrite - 2.0 added SMP and support for different architectures. The second field is the minor revision number. I say minor because the changes added here are generally not drastic enough to warrant incrementing the major revision.

The third number could be called the patchlevel, though its not incremented with every submitted and accepted patch the way Xfree is. An incremental patch for the linux kernel is pretty much always a coalition of submitted patches cooked up by the maintainer.

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

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.

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.

Detailed Reviews of the kernel

Joe Pranevich on The Wonderful World of Linux 2.6

Getting and compiling the kernel

Well, since you've got this far, I'll presume you actually want to go ahead and try the kernel. You can find source at http://kernel.org. The procedure for compiling 2.6 is exactly the same as 2.4 (unpack, make menuconfig, make bzimage, make modules, make modules_install). If you dont understand that statement, you probably shouldnt be doing this by hand - head over to http://kernelnewbies.org and RTFM before going any further.

You'll notice in the menuconfig several things have moved about. There is now an option for architecture and a seperate option for processor family, for instance, whereas in 2.4 these are combined. The list of platforms Linux supports is now so long that Linus felt the need to split architecture and family to make it easier to choose the right options. Other new entries include support for kernel accelerated crypto (you can build crypto algorythm support as modules or directly into the kernel). There is also support for additional (nazi) security regiemes like grsec which can protect your machine from some kinds of tampering, but is generally an annoyance. Of course these arent the only new entries, you can find and explore them yourself.

(Lazy RedHatLinux users can see KernelNotes for prepackaged RH kernels).

Nvidia notes

Originally, Nvidia did not support 2.5/2.6-test kernels - patches (http://minion.de) were required for the NVIDIA-kernel driver 2?. Nvidia drivers version 1.0-5336 and later support 2.6 kernels. However, this driver DOES NOT WORK if the kernel is compiled with the option to use "4k stacks", which the kernel distributed with FedoraCore 2 uses. This should be fixed in later versions of the nvidia driver (when released).

ModuleInitTools

Starting with 2.5.51, Linus merged a new way of handling modules. He's added versioning on every symbol inside a module, with the intent that the kernel can read the module and what hooks it uses, compare it to an internal database of whats critical and whats not, and can decide whether the module could be used even if it wasnt compiled specifically for the current running kernel. This adds a lot more flexibility for people forced to run binary-only proprietary modules to support their hardware. What this means for the user is a completely rewritten set of module tools (modprobe(8), insmod(8), lsmod(8)). On Debian you can get these with a quick

apt-get install module-init-tools

Module-init-tools is backwards compatible with 2.4.x kernels, so if you're dual booting between a stable and a beta kernel, you've got module functionality on both. (Read ModuleInitTools for an important caveat!)

Important: module-init-tools no longer reads modules.conf and instead uses a new file called modprobe.conf(5) which has a different syntax. 'man 5 modprobe.conf' will be your friend here. It's possible to set modprobe.conf to handle modules for both 2.4.x and 2.5.x kernels, which is pretty cool if you're a dualbooter.

Also you may notice that the extension of modules has changed from .o to .ko, for kernel object.

Debian Woody and 2.6

As mentioned above you need at least a new version of module-init-tools - you will need to use backports to get updated

versions of some important packages. Add the following two lines to your apt sources.list
  1. kernel 2.6 and related things

deb http://www.backports.org/debian woody kernel-2.6 deb http://www.backports.org/debian woody module-init-tools

and install/update module-init-tools, modutils (if you want to dual-boot with a 2.4 kernel), hdparm, and procinfo.

dhcp server

If you install 2.6 on a machine running a dhcp server, then the default woody startup script won't work. The "dhcp", version "2.0pl5-11" has two separate binaries, one for 2.0 kernels and one for later kernels. Unfortunately, the /usr/sbin/dhcpd shell script tests if your kernel version is either 2.0, or 2.x (where "x" is between 1 and 5, inclusive). Edit the shell script and add a "6" to the part that says [12345?.


For anyone who tries a 2.6.x kernel early in the game, here is a place to record your experiences.

'I have tried (2.5).62 through .66. .62 appears to be the most stable with .66 second. I do run a lot of OpenGL apps (read: Quake III Arena) though, and it's more likely to be the Nvidia driver thats causing my system instability. As far as performance goes: 2.5.65 with the ingo-linus scheduler was by far the fastest in interactive applications. In general I get about a 30% increase in framerate (under glx) but of course this comes at the cost of stability. WineX? also feels a lot faster (thought there is no framerate gain according to ingame displays - I've tried CS and Ghost Recon] - TomHibbert'

'Tried a generic 2.6.0 from kernel.org on Fedora Core release 1 (Yarrow) using SoftwareRaid. When running the make install it complains when creating the initrd image and the raid1 module not being present. The bzImage loads fine when testing it manually, and seems to run sofar. -- GerwinVanDeSteeg'

Compiled 2.6.5 under Debian Sarge, monolithic (no modules, compiled in everything I use) and pre-emptable. It feels very responsive! Been using it for a few days already. - zcat(1)


1? Originally unusual; now Gnome and Evolution (to name a few) use it.

2? Interestingly enough, in order to get the above working, I had to add the line
  1. define kdev_val(d) ((unsigned int)(d))

To the nv-linux.h file of the aforementioned driver (version 4496) in order to get it to work. Others appear to have had no trouble with it, perhaps someone could shed some light as to why this is?