Some kernel hackers believe that the code responsible for write barriers has been overly restrictive in various places. A major restructuring effort is to put an end to this and transfer the main responsibility for determining the order of write operations to the file system code, a solution said to considerably improve data throughput with certain tasks. Control groups (cgroups) now allow the maximum throughput of storage devices to be limited / restricted; details are available in various commit comments (1, 2, 3, 4) and in the updated documentation.
The Libata subsystem now cooperates with hard disks which use logical, as well as physical, sectors that are not 512 bytes in size; the developer has tested the code with a native 4K "Engineering Sample" drive provided by Hitachi GST. In the SCSI subsystem, and in the Libata code based on it, the developers have made various major changes that restructure the locking mechanisms to speed up certain drivers (for instance 1, 2).
Which drivers were changed
Information about the changes to individual Linux kernel files can be found through the Git web front end at Kernel.org – this, for example, allows users to find out whether there have been changes to the drivers used on their own systems. To do this, however, users need to know where in the Linux kernel's source code tree the driver files are located. For the heavily modular distribution kernels the modinfo program is often helpful when searching:
$ /sbin/modinfo e100 e1000 | grep filename:
If a compiled module is, for example, located at [...]/kernel/drivers/net/e100.ko, its source code in the Linux source code archive can usually be found in a file with a similar name in the drivers/net/ directory – for example e100.c for the e100 driver for Intel 100 MBit networking hardware. Other modules, such as the e1000 driver for Intel's PCI Gigabit LAN chips, on the other hand, have a whole directory to themselves. If the approximate location of the driver source code is known, users can navigate to the respective source code files in the tree view of the Git web interface and then retrieve an overview of the latest file or directory changes via the history link. In the network driver directory, changes to the driver code of e100 (drivers/net/e100.c) and e1000 (drivers/net/e1000/), for example, can be displayed and examined in this way.
Changes contributed to Linux 2.6.37 by the Xen development team include 'initial domain support', which adds functions for running the kernel as Dom0 (see e.g. 1, 2, 3, 4, 5, 6, 7). This is of little use to Xen users for now, as drivers for setting up the Xen back end, to allow a guest system to access storage devices and networks, are not yet available. The Xen development team is planning to submit the code for this for merger in 2.6.38, so that it will be possible to run as Dom0 from this version. This, and the Xen code now integrated into the kernel, are however, trimmed down versions, offering less functionality than current versions of Xen or Citrix' XenServer.
A VMware developer has, as planned, removed support for VMI (Virtual Machine Interface), VMware's para-virtualisation interface, from the Linux kernel. This is no longer considered worthwhile now that x86 CPUs with virtualisation technology, able to achieve better performance than para-virtualisation, are becoming the norm. Background information can be found in a blog entry on the VMware web site.