In spite of the recent security attacks on kernel.org and other Linux community infrastructure, the show must go on and kernel development continued – albeit heavily disrupted at first by the various outages. That didn’t stop patches being posted adding support for two brand new architectures to the Linux kernel. One of these architecture patch postings targets a new DSP (Digital Signal Processor) design from Qualcomm called Hexagon that is commonly found in combination with a more powerful ARM processor within Qualcomm system-on-chip (SoC) processors – that’s two cores, both running different Linux kernels on the same chip.
Unlike other DSP ports of Linux, Qualcomm’s Hexagon is fully featured: it has support for SMP (symmetric multiprocessing) and uses a built-in hypervisor like many other newer chips (the Tilera Tile comes to mind as a recent example). But even more interesting than the Hexagon perhaps is the fact that Linux 3.1 will be the first shipping kernel to support the OpenRISC open source CPU architecture. Those who enjoy playing with FPGAs (field-programmable gate arrays) can build an OpenRISC computer at home and run a stock Linux 3.1 kernel on it without making modifications.
The security troubles with kernel.org have certainly had an impact on the overall Linux 3.1 development cycle. In addition to being unable to post some development trees (due to corporate policies requiring some to use kernel.org), many had their workflows upended by the loss of fairly critical infrastructure.
Linus was able to continue to post changes to his kernel tree newly hosted on github.com, taking the version to release candidate 3.1-rc8. There were a few automount and USB issues, but generally Linus said “it really is getting quite calm”. The bigger issue was how to handle the impending merge window (the period of time following a release during which Linus allows disruptive changes that will make it into the next release) without the regular kernel.org facilities.
In the end, Linus decided that he’d like to avoid doing a merge window without the availability of kernel.org systems, electing to postpone the 3.2 merge window until after he returns from a vacation in the hopes that at least core infrastructure such as git.kernel.org will be available upon his return. That’s something everyone is hoping will be true at this point, though some are also beginning to point out that the slipping of the merge window will likely mean a lot of churn is happening right around the time of next month’s Kernel Summit in Prague. That might make for a rather light merge window as far as getting patches from kernel developers who are disconnected during travels.
Finally this month, the latest util-linux 2.20 was announced, featuring the removal of support for Discordian dates (ddate). This generated more traffic on distribution and kernel mailing lists than one might reasonably have expected, leading Valdis Kletnieks to wonder if there were actually any Discordians left, “or did they all go corporate and had their discordianism surgically removed?”. Kernel developers are an amusing bunch sometimes.
The x32 ABI
The 2011 Linux Plumbers Conference took place in Santa Rosa this month. This is an annual gathering of Linux developers working on core ‘plumbing’ of the overall systems architecture within modern Linux systems, including kernel developers and those working on user-space software interacting with the kernel.
Among the talks was a very interesting presentation on a new ABI for Intel64 architecture (x86-64) systems, the ‘x32’ ABI. This work was presented by some of the team from Intel that are trying to get the work merged into the kernel.
All architectures require a strongly defined ABI, or Application Binary Interface, that codifies how applications will interact with the kernel (and other applications) at the binary level: which registers will be used for function arguments (parameters), what is the minimal stack alignment required when calling into a function, and so on. The existing ABI in use on these ‘x64’ systems is well understood, having evolved over many years to the point it is at now. It is, however, not always as efficient as it might be. Being a pure 64-bit ABI built upon the original AMD 64-bit extensions added to the x86 architecture means that 64-bit registers are always used for function arguments and pointers, even if the application doesn’t actually need to use more than 32-bit data values and memory addresses.
The ‘x32’ ABI addresses a need for certain applications to have access to the full 64-bit instruction set available on modern Intel processors, including all of the added registers (as compared with the older 32-bit design) but without the performance hit of requiring 64-bit data and memory addresses.
By allowing for these to be 32-bit quantities, better utilisation can be made of limited size caches and so forth. Of course, if this sounds great, you’re probably wondering why it wasn’t done sooner, or what the catch is. The catch is that x32 is an ABI that is incompatible with every pre-compiled application available for Intel systems today (including legacy 32-bit apps). It can be used on the same system as the conventional x64 ABI, but it requires new libraries and a new set of kernel system calls in a new kernel.
Therefore, at the moment, it is mostly of interest to embedded developers who are willing to rebuild the entirety of their applications for a certain amount of performance gain. Everyone else is likely to stay with the existing ABI for the foreseeable future. For more information, head on over here…
Jon Masters publishes a daily Linux kernel mailing list summary at kernelpodcast.org