« previous 1 2 3 4 5 6 next »

Cornucopia of new and updated drivers

In addition to the improvements to hardware support already mentioned, the developers integrated, as usual, numerous additional drivers or improved existing drivers along with their surrounding subsystems. The eeepc-laptop driver was added. It handles special features of the Asus EeePC, among them the ability to adjust the background illumination and the fan. Support for OLPC notebook architecture was also added to the kernel.

Numerous other patches make changes to the sound drivers maintained by the Alsa project. The change to the virtuoso driver, for instance, provides support for the Asus Xonar DX soundcard. A new Alsa driver optionally attempts to play audio output through the PC speaker, usually integrated into the computer housing, that makes the classic beeping sound. Developers, however, advise against activating the driver to avoid unintentionally playing back audio through the PC speaker instead of the soundcard.

In addition, the kernel sound drivers also support the HDMI sound controllers found in the recently introduced GPUs of the newest generation of Radeon graphics cards. Numerous other changes listed at the end of the article correct bugs, expand driver capabilities, or ensure with a whitelist that the special treatment necessary for audio hardware on many PCs, motherboards, and notebooks is used automatically.

There was also activity in the Video4Linux drivers for TV and video hardware – among other things, support for hybrid tuners was optimised considerably. Linux 2.6.26 for the first time includes the cx18 driver for TV cards with the Conexant cx23418 (e.g. the Hauppauge HVR-1600), the mxl5505s driver for 5505 MaxiLinear chips, along with the au0828 V4L driver provided by a Hauppage employee for HVR950Q, HVR850 and FusioHDTV7-USB Hauppage hardware. The cx23885 now also supports the Conexant cx23417 hardware encoder.

Rather late in the development cycle, Dave Airlie suggested integration of a large collection of DRM patches that synch the microcode for Radeon graphics cards with the code released by AMD and add 3D support for R500 GPUs in the kernel's direct rendering manager. Torvalds integrated the patches despite the late submission and their size. This addition means that for the Radeon X1000 series all that is needed for 3D accelleration in addition to Linux 2.6.26 is a new version of either the ati or radeonhd X.org driver and a current version of Mesa.

Following a period of relative inactivity for the IDE subsystem, lead developer Bartlomiej Zolnierkiewicz has spent the past few months thoroughly overhauling and tidying up the IDE code (1, 2, 3, 4, 5). He continued this work in 2.6.26, removing numerous kernel parameters in the process and adding support for warm plug (see attachment). This means that the IDE subsystem will reside a bit longer in the Libata subsystem parallel to the PATA drivers. However, most of the new distributions either give preference to the Libata drivers or use them exclusively.

The Juju FireWire stack, integrated in 2.6.22 also saw additional improvements. The new cdc-wdm USB driver talks wireless to mobiles and modems equipped with CDC WMC. As of version 2.6.26, the kernel will offer a simple driver for braille screenreaders for the visually impaired.

With all of the new and updated drivers, others had to make way. Developers removed the sk98lin driver for Marvell LAN hardware, for instance. This driver, originally developed by the chipset manufacturer, has not been maintained in the kernel source for quite some time – ever since kernel hackers developed the skge and sky2 drivers from the ground up as replacements for sk98lin.

Back and forth

In this development cycle too, kernel developers added some change or other, only to remove it later. Ingo Molnar introduced a patch limiting the stack size that the x86 32 kernel in the standard configuration uses to 4k per process/thread. This resulted in a rather drawn out discussion about the various advantages and disadvantages, as well as the side-effects of 4k stacks reminescent of similar discussions held in previous years. Finally, the change was withdrawn – it remains to be seen whether someone will try to push such an initiative again, or whether 4K stacks as the standard for x86 32 systems will be forgotten as x86 64 CPUs and distributions become the standard.

But the patch making 4K stacks the standard was hardly the only one that the kernel hackers tossed out – there was a total of nearly forty patches that were integrated into the kernel only to be removed prior to release. Among these was the nearly 150 KB UDP patch in the network subsystem, as well as various CFS improvements. At least some of these changes are likely to show up again in an improved form in Linux 2.6.27 or later kernel versions.

Miscellany

Along with the back-and-forth on the patches, there were numerous discussions and developments likely to have an influence on the future of the development process. Several debates – some of them rather involved – in which many of the big name developers took part centred on the excessive speed with which new patches are integrated into the main development line and their subsequent lack of quality. Many of the developers claimed that the snapshot feature in the Linux source code administration system often either did not compile during the merge window, or was not even used. This, the kernel hackers emphasised, resulted in many patches not being adequately vetted prior to integration.

Al Viro and Andrew Morton agreed that patches intended for integration into the main development line needed to be more visible to to other kernel developers – this would allow the changes to be modified if necessary in a timely manner and without a lot of fuss before Torvalds entered the patches into the source code administration system. For his part, Torvalds made it clear that he had no intention of slowing down the rate of patch integration. He also denied the request to extend the merge window; on the contrary, he preferred shortening it.

At present it is difficult to predict what consequences this multifaceted discussion (recounted here only in broad strokes) will have on the Linux development process in the long term. However, there seems to be a unanimous view that a bit of optimisation in the development process is long overdue. At least some kernel hackers had already realized this and founded the linux-next development branch last February. It merges developments in the various subsystems with those of the kernel hackers, developments intended for the Linux version after next (i.e. after the release of 2.6.26, they will be working on code for 2.6.28).

This allows developers to coordinate their patches with one another; the updatesare also archived in bundles by area, which makes it easier for testers to access them. Finally, linux-next makes it easier for kernel hackers to get an overview of where other kernel hackers' developments stand, giving them an opportunity to critique each other's work before Torvalds actually integrates the changes into the main development branch.

After Andrew Morton, recently interviewed on LWN.net, spent several months keeping an eye out for a maintainer that would be responsible for embedded systems, Paul Gortmaker (Windriver) and David Woodhouse (until recently employed at Red Hat) stepped up to take on this role; they discussed their plans straight away in an interview.

More: What's in store in 2.6.27 and beyond

« previous 1 2 3 4 5 6 next »