Notice: Undefined index: order_next_posts in /nas/content/live/gadgetmag/wp-content/plugins/smart-scroll-posts/smart-scroll-posts.php on line 194

Notice: Undefined index: post_link_target in /nas/content/live/gadgetmag/wp-content/plugins/smart-scroll-posts/smart-scroll-posts.php on line 195

Notice: Undefined index: posts_featured_size in /nas/content/live/gadgetmag/wp-content/plugins/smart-scroll-posts/smart-scroll-posts.php on line 196

The kernel column with Jon Masters – 2012: the road ahead

Jon Masters shares his thoughts on what 2012 holds for Linux kernel development…

In the shorter term, several long-standing issues are likely to be put to rest, including ARM sub-architecture cleanup, the final merging of support for Microsoft Hyper-V, and generalisation of various kernel subsystems that had historical ties to specific architectures. Such generalisation will, for example, see the reconciliation of code paths that support ACPI-driven platform device discovery on x86 systems and device-tree-driven platform device discovery on non-x86 systems. Platform devices include all of those peripherals and buses that cannot be automatically enumerated, including the initial discovery of the system PCI root(s). Reconciliation between the different discovery mechanisms will see shared code and common in-kernel infrastructure regardless of the actual underlying approach used by hardware.

ARM sub-architectural cleanup will see further de-duplication of code between the many different supported sub-architectures (variants) of ARM, and a continuation of the ongoing work to produce a unified 32-bit ARM kernel binary capable of supporting many different systems. Historically, having a single kernel image for ARM has not been a priority since these systems have typically been heavily vertically integrated embedded systems. But in the emerging space of general-purpose ARM-based computers and servers, it will be increasingly important that Linux vendors can provide a single OS image able to support a wide variety of possible installation target systems. It is likely that the initial effort will produce options for compiling a kernel containing support for many variants of the same sub-architecture, but this will become increasingly generic as code is refactored underneath.

Microsoft Hyper-V support is another area where there is likely to be some action in the shorter term. At this point, KY Srinivasen and the Microsoft team have been developing support for their hypervisor technology within the Linux ‘staging’ tree (drivers/staging within the source code) for some time. Greg Kroah-Hartman and others who are involved in maintaining the staging tree do so as a means to provide a place for nurturing new driver code not considered ready for prime time. Drivers generally land in staging, are improved over a period of a kernel release or two, and are then moved out of staging and into the mainline kernel. Except in the case of Hyper-V, which has been in staging since mid-2009. At this point, however, it seems that the code is finally ready for a general review by the many different subsystem maintainers whose parts of the kernel are to be affected by Hyper-V support being included. It has not been an easy ride for Microsoft, but it may be over very soon.

Development will continue to take place largely as it has done, in roughly three-month release cycles, punctuated with increasingly short ‘merge windows’ (during which disruptive changes are allowed) and subsequent periods of stabilisation. The linux-next tree built by Stephen Rothwell on a daily basis from the collected trees of many different developers will continue to be the central nexus for new feature development and testing prior to gaining approval for inclusion into an official Linux release, while the staging tree will continue to be the place for new driver development (it is hoped that linux-next will include the staging tree in due course to allow for testing of interactions between the two).

Overall this means that the established development workflows will continue to be the status quo in 2012 with little to no variation.

Further out, and perhaps lasting beyond the next year, there are likely to be some significant changes to the kernel if Linus follows through on his recent leanings towards merging Android patches. In recent mailings, Linus has acknowledged that the millions of users of Android devices should not be ignored by the kernel community. Many Android patches remain outside of the official kernel (instead, they are contained within the official Android kernel, which is maintained by Google). There have been attempts to merge specific sets of Android patches into the official kernel, with some success, but there is a long road ahead to reconcile all of the differences. We will continue to cover these changes each month in
this column.

Finally, some things may never change. The year 2012 will begin with the RT (Real Time) kernel patches still being maintained outside of the official Linux kernel and it will likely end in the same fashion, albeit with the set of patches progressively shrinking over time. There are many people now using the Real Time patches in production environments, both at the large (stock markets) and small (mobile phones) ends. The patches are well proven and reliable, but there is still a level of disruption there in terms of performance overhead imposed on those who do not want Real Time features.

Once there is an ability for compile (or runtime) zero-overhead disabling of the Real Time support, then the patches are likely to be merged.

Ongoing development
Linus Torvalds announced the latest 3.2 release candidate kernel “just in time for [the US] Thanksgiving” holiday, in one of his typically humorous emails beginning “Hey, since most of the US will be in a food-induced coma tomorrow, I just know that doing a new release candidate is a good idea”. The final 3.2 release may be out by the time you read this. It includes a number of new features (which will be covered in a future issue), the removal of many lines of old code that is no longer required, and fixes for some important bugs (such as a severe RAID regression that was present in 3.1 and should be resolved by an updated 3.1.z release by your preferred distribution).

This month saw the publishing of a ‘Plumbers Wish List’ for Linux. The core guts of any Linux system are often referred to as its ‘plumbing’ and those who work on such pieces of infrastructure are known as ‘plumbers’ (hence the name of the Linux Plumbers Conference). The Wish List, which was published by several prominent developers, includes both mundane and more exciting future features, all of which should combine to offer an improved user experience. On the list were finally providing a means to modify a FAT file system label without unmounting it first, changing the name of a process (argv) without playing with environ settings, and detecting if a process is running within a container (a separated namespace). The full list is available in the Linux Kernel Mailing List archives, which you can find here.

A collective decision has been made that a new TAINT_OOT_MODULE flag be introduced for out-of-tree (non-upstream) kernel modules. This will mark all loaded kernel modules that are not shipped with the kernel in such a way that any diagnostic kernel output (from an oops, say) will include the special TAINTED status. At the same time, a change to the kernel will no longer disable certain functionality – in this case tracing – when a TAINT flag is set. As the original author of the TAINT flag support notes, they are supposed to convey information, not determine kernel behaviour. If a system administrator wants to load a binary kernel module that is not compatible with their kernel, they have bigger issues to worry about.

Finally, Ted T’so and Ingo Molnar had an interesting debate in several threads focused on whether utilities and tools designed to work with the Linux kernel should be developed within the kernel source tree. Ingo’s work on the perf (performance monitoring) tools takes place in a tools subdirectory of the official Linux kernel source, something that he claims improves overall code quality because the development is so tied to that of the kernel. Meanwhile, Ted and others note that this close relationship between a tool and the kernel source could actually serve to be detrimental to maintaining a strictly compatible ABI (application binary interface) between the kernel and such tools across multiple releases. Others point out that there are limits to what can be carried in the kernel source tree. Perf utilities are one thing; a simple tool to manage Linux KVM virtual machines now being proposed may be quite another.