« previous 1 2 3 4 5 6 7 8 9 next »

Important things that happened during the development of 2.6.27

Many other discussions during the development of 2.6.27 are important for the future development of Linux. Linus Torvalds emphasised in a discussion on the Linux Kernel Mailing List (LKML) that nothing could make him go back to the old "unstable-series" development model; the current model is so much better, he said, that it's not even worth thinking about creating a 2.7 series saying "I'm not going back to the old model. The new model is so much better that it's not even worth entertaining as a theory to go back." In the course of this discussion, however, the father of Linux let on that he is thinking about adapting the numbering scheme to create version names like Linux 2008.10. This topic was expected to be discussed at the Kernel Summit 2008 held in mid September – so far, however, the reports from the conference have not contained any information about whether the issue was discussed.

During the development of 2.6.27, Linus Torvalds put the brakes on some of the developers, prompting them to stick to their scheduled troubleshooting tasks in the second phase of the development cycle; major changes should be kept back for the next kernel version. If developers better adhere to this rule in the future this could slightly shorten the development time of new Linux versions – lately, the originally planned stabilising phase of about six weeks was often stretched to nine or more weeks because some of the mistakes introduced with the changes incorporated during the merge window could only be corrected slowly and because some of the big changes introduced at a late stage triggered new problems.

At the kernel summit, the kernel developers even almost agreed on shortening the development cycle to a total of six weeks – this idea was discarded in the end, however. The support for ISA hardware and other obsolete and scarcely maintained code (for example first generation Video 4 Linux) are to be kept in the kernel for now rather than being thrown out, as demanded by Alan Cox at the developers conference. Find further information about this and other topics discussed at the Kernel Summit 2008 in two kernel logs at heise open which summarise the discussions held on day one and two.

A how-to of kernel development

In the recent document "How to Participate in the Linux Community" published by the Linux Foundation, LWN.net founder and author Jon Corbet explains many background details of the kernel development process. In the document, he offers many tips on how to get into kernel development and avoid beginner's mistakes in the code and when co-operating with established kernel hackers. This should not only be a big help for amateur programmers wanting to become part of the Linux kernel community but is also designed to give businesses unfamiliar with the open source and Linux development concept an insight into the Linux development process. This seems to be more than overdue as many hardware vendors and driver programmers have stumbled badly when trying to get into Linux and open source development. Corbet and the Linux Foundation are not the only ones to address this topic: In his presentation "On submitting kernel patches" at the OLS 2008, Andi Kleen gave a very similar although slightly shorter overview.

How important stable interfaces for userland applications are to Linus Torvalds is indicated by a discussion on the LKML during the development of 2.6.27. An alteration planned for 2.6.28 caused the current version of the X.org synaptics touch driver to malfunction; however, this was not due to a kernel problem but a bad and previously unknown bug in the touch driver which only came to light through the change to the kernel. Urged and assisted by Torvalds, the kernel developers finally craftily modified the kernel patch that triggered the flaw to allow the current driver versions to co-operate smoothly with future kernel versions.

More trust in your distributor

Those who prefer to compile and install their own kernels should reconsider whether to keep up this practice or switch to a precompiled distribution kernel instead. After long debates about marking security changes when releasing a new kernel, the kernel developers now don't even give information about whether a new kernel corrects any security issues; instead, the maintainers of the stable series have advised the users of Kernel.org kernels in their release emails since 2.6.25.13 to upgrade to the newly released version ("Any users of the 2.6.25 kernel series should upgrade to this version"), adding that details about the changes can be found in the Git web interface or in the changelog.

A closer look at the latter reveals corrected security issues in some but not all of the versions announced in this manner. In 2.6.25.13, for example, there is a discussion of CVE-2008-2750, a security problem in the kernel's PPP code already previously fixed via kernel updates in Fedora, OpenSuse and Ubuntu. Security-conscious users of selfcompiled kernels are, therefore, advised to install every new version of the respective stable branch. This should be considerably less work than searching for security corrections in a new kernel version's changelog, a time-consuming endeavour which can only be carried out reliably by security experts. A precompiled kernel of the chosen Linux distribution maintained by a distributor is likely to remain the best choice for the majority of users – this was also advocated by quite a few kernel developers during the discussions mentioned earlier.

Next: Statistics, conclusion and outlook on 2.6.28

« previous 1 2 3 4 5 6 7 8 9 next »