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

Infrastructure improvements for all

Linux 2.6.27 is the first version to offer the Ubifs (commit, documentation, background article) file system. This file system was designed for Flash memory media without wear levelling and is based on the Unsorted Block Images (UBI) features introduced with 2.6.22. The Ext4 file system in 2.6.27 can, for the first time, handle delayed allocations (1, 2). This is designed to increase performance and reduce file fragmentation; find detailed background information about this technology in one of the many presentations covering the Linux kernel and its environment at this year's Ottawa Linux Symposium (OLS). The Ext4 file system continues to be flagged as a development project unsuitable for productive use, but this is likely to change in the near future.

Quite a few file systems optimised for Flash media, SSDs or hard drives, such as AXFS (Advanced XIP File System), btrfs and nilfs2 (New Implementation of a Log-structured File System Version 2]) are aspiring to be integrated into the Linux kernel at some stage – combined with other experimental file systems like Tux3 or Reiser4 (which continues to simmer but hasn't taken off again), the coming months and years are guaranteed to offer plenty of material for endless debates and performance tests to find the "best file system", a question which has time and again been discussed by many users in greatest detail.

Rearranging the firmware

Several of the patches integrated with 2.6.27 considerably change the handling of the firmware used, for example, by many LAN, Wi-Fi and SCSI chips. Some of the patches predominantely modify old drivers, enabling them to load the firmware via the Initrd firmware loader or the root filesystem like modern drivers instead of integrating the firmware directly into the kernel module or the kernel – the latter can, however, still be configured. Other patches, however, now also allow the firmware images to be attached to the kernel image, enabling the drivers required especially early on in the boot process to request these images via the firmware loader, even before Initrd or the root filesystem have been launched. Previously, these drivers had to contain the firmware image as part of the driver code.

All these changes caused quite some controversy and resulted in long and sometimes heated discussions. The two maintainers of the network subsystem and the network drivers were particularly reluctant to integrate the changes, resulting in network drivers like tg3 or bnx2 which still, for now, contain their own firmware. It is unlikely that open source purists and Linux distributors will, in the near future, be able to compile universal kernels containing all the firmware-dependent drivers but not the firmware – often only available as a precompiled binary without source code – itself. This is what several open source enthusiasts had repeatedly and vociferously called for in a Fedora mailing list, eventually prompting former Red Hat developer David Woodhouse to develop the changes which have now been integrated into the main development branch.

All about drivers

The subsystems around the drivers also offer some new functionality to users and driver programmers. New in Linux 2.6.27 is the Linux TX Multiqueue Implementation largely programmed by David S. Miller, the maintainer of the network subsystem. The feature adds the basic requirements for networking hardware with multiple transmit queues to the network stack. Many modern Wi-Fi chips offer this functionality to allow, for example, video or audio data to be transmitted at a higher priority.

Developers also made extensive changes to the infrastructure surrounding the use of system sleep states. One of the changes now allows drivers to perform different tasks when changing to or from ACPI S3/Suspend to RAM state from tasks performed before or after a Hibernate/Suspend to Disk state; this was integrated to remove some of the basic problems with these two sleep states. The presentation Suspend-to-RAM in Linux - State of the Union Address gives background information about these changes and offers more details about ACPI and about the code for using system sleep states.

The "block layer data integrity support" also integrated with 2.6.27 (commit, documentation, background article) is also described in detail in one of the OLS presentations – this technology is designed to allow storage controllers for servers with suitable drivers to monitor whether the data arrived correctly on the storage media. The SCSI subsystem now also supports the SCSI disk (SBC) Data Integrity Field.

Numerous changes eliminate Big Kernel Lock (BKL) calls in the higher kernel layers or shift the calls to a lower level – for example, moving calls from the various driver subsystems into the underlying hardware drivers. This allows the latter to ensure the integrity of critical code sections – a vital process in multiprocessor operation – on a highly individual basis and only if absolutely required. Using this more highly defined locking mechanism, kernels should be able to offer improved scalability especially in systems with multiple processors. Desktop PCs are also likely to benefit to some degree through better performance. In the long run, the kernel developers intend to completely remove the Big Kernel Lock; the current changes are only the first steps in this process which is likely to take several years to be completed.

Next: A host of new drivers to improve hardware support

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