Kernel 3.19 development – the kernel column

Jon Masters summarises the latest happenings in the Linux kernel community as work continues on the 3.19 series kernel


Linus Torvalds, freshly returned from speaking at Linux Conf AU (LCA) 2015, announced 3.19- rc5 saying “[a]nother week, another -rc”. His announcement mail included his usual opening about his desire for less churn late in the development cycle (Linux kernels typically have up to 8 RCs – or Release Candidates – in the two months of the average release). Overall, Linux 3.19 is shaping up to be a normal sized release – though there’s still well over 10,000 individual commits or patches, each with many lines, which isn’t bad when you consider how the development largely aligned with the end of year holiday period. The new kernel will add a few exciting features, including support for Intel’s MPX processor extensions, and the nios2 embedded system microprocessor architecture from Altera.

Looking further out beyond 3.19 and into the new year, it is interesting to consider that we have another 3 or 4 kernel development cycles coming up over the next few months. That’s where we would like to hear from you. Drop us a line and let us know what exciting kernel development projects you have in store for the year and what you would like to see featured in these pages. Linux User & Developer aims to provide you with fresh and original content, and we are always willing to take on deeply technical topics in our quest to help you learn more about how Linux works inside.

Intel MPX

Perhaps the most exciting feature merged for Linux 3.19 is support for the emerging Intel MPX technology. Memory Protection Extensions (MPX) are an ISA (Instruction Set Architecture) addition to the venerable x86 instruction set that can be used to increase software security by automatically guarding against certain buffer overflow and other generic ‘bounds checking failure’-type security flaws. In other words, MPX isn’t particularly sexy in terms of end users having something shiny to play with, but it stands to provide a significant improvement in security that users will certainly appreciate.

MPX works by introducing some new system registers and special instructions, that supporting compilers (including the GCC) can emit during code compilation to cause those registers to be programmed with additional information about a program, such as the ranges of memory to which it intends to have access. As an instruction set extension, MPX will have no impact on existing applications, but new or existing code can be recompiled to take advantage of this feature. Since many software applications are routinely rebuilt and upgraded, and MPX can be enabled with very little work on the part of the programmer (the compiler takes care of most of the details), it is likely that we will see a growing adoption of this technology over the next few years. This is a good thing, because it takes years for new hardware features to make it into a market that can provide such capabilities. It’s certainly time security improved.

“Out out damn perl”

Rob Landley posted a patch that (re)removed a build dependency upon the Perl scripting language being required to compile a Linux kernel. As a complex software project, Linux has dependencies upon various external tools like compilers and assemblers, but is generally (surprisingly) lightweight in terms of its requirements – at build time, at least. You can compile a kernel on a Raspberry Pi (if you have a lot of time to kill) – it’ll just take a lot longer than it would on your desktop or laptop. It was this flexibility to compile Linux in many places that Rob was seeking to preserve in mailing.

At first blush his patch, which was entitled “out out damn perl”, might seem overly harsh upon our obfuscated Perl-coding friends, but Linux has a good track record of keeping its build requirements modest (and free of much more than a shell for scripting purposes). The resulting discussion centered around separation of build from development tools. It is reasonable to require Perl for certain development and kernel maintainer activities. For example, Linux ships with an infamous script called ‘’ that verifies whether patches submitted by developers for inclusion meet the Linux coding style guidelines and community conventions. Of course, this script itself being written in Perl caused a number of jokes suggesting that it should be modified to warn whenever it was run with a Perl warning.


Linux 3.19 will include support for the AMD “KFD” kernel driver. This is part of their HSA (Heterogenous System Architecture) Foundation work which seeks to produce a completely open source solution for developing and using GPGPU- based technology with Linux. The KFD works a bit like the existing Linux DRM (Direct Rendering Manager) in communicating with a ‘Graphics’ Processor Unit (that might not actually be capable of graphics), except KFD doesn’t care about actually driving a display. What it does instead is load ‘kernels’ (nothing to do with the Linux kernel) of compiled GPU programs onto the GPU and manage them at runtime so that the results of computions can be returned. Using KFD, along with other HSA tooling (such as the r600 OpenCL LLVM Clang-based compiler) will make for a fun project for this author over the coming weeks. AMD have example projects available at their HSAFoundation GitHub, including a Matrix multiplication demo.

Ongoing Development

Alan Cox, in following up to another thread on maintainer abuse (which focused on what to do about submissions of patches that happen in the middle of the frenzy of craziness that is the merge window during the first couple of weeks of a kernel development cycle), asked whether it was “the year for a Google summer of code project or similar to turn Patchwork into a proper patch management tool”. Patchwork is used by a number of kernel folks to track patches that have been posted, revised and merged, but it is far from a polished product with the kinds of capabilities that Alan and others would obviously like to see being made available as Linux continues to grow.

Seth Jennings, Jiri Kosina and many others have been involved in a number of conversations around unifying the approach to Kernel Live Patching. A variety of different projects exist (and of course, there was also the previous Ksplice project that ultimately went more proprietary) that aim to provide live patching to a running kernel. It is hoped that a number of the developers will meet at the upcoming Linux Collaboration Summit and hash out a plan for a collaboration that will land initial support in 3.20. This would be the first time that an upstream kernel had such a solution.

This author posted about adding support for the SPCR (Serial Port Console Redirection) ACPI table in Linux. This feature will obviate the need to supply ‘console=’ parameters on servers because the kernel will be able to determine this automatically, based upon platform data provided by the system vendor that has been supported in Microsoft Windows for years.

Dan Carpenter announced that version 1.60 of Smatch, his static C language type checker, is available. Smatch understands many Linux kernelisms and is a useful tool for verifying kernel code.