Kernel 3.13 – The Kernel Column
Jon Masters summarises the latest happenings in the Linux kernel community, including the release of 3.12, the 3.13 merge window and new Jailhouse hypervisor
Linus Torvalds announced the release of Linux 3.12, saying that he had “vacillat[ed] on whether to do an rc8 or just cut the final 3.12”. In the end, he opted to forgo a 3.12-rc8 and went straight to release, before taking off for a week. Therefore the traditional merge window for 3.13 did not open immediately, but instead was preceded by a one- week delay. Linus also closed the merge window for 3.13 a little earlier than two weeks after it opened. In his announcement of 3.13-rc1 (Release Candidate 1), he called out the fact that he had released on a Friday rather than his “traditional” Sunday, and noted that “if you were planning on sending in the last two days… I can only laugh derisively in your general direction”.
New features in 3.12
Linux 3.12 adds some nice new features, such as automatic GPU switching on laptops, and offline deduplication in the ‘next generation’ file system Btrfs. Deduplication is what it sounds like: automatic handling of duplicated file content (at the block level) by storing only a single copy of the corresponding data and updating all references to point to the (shared) copy instead. The ‘offline’ nature of deduplication (often known as ‘dedupe’ in the industry) in Btrfs means that it is currently only performed at the direct invocation of a special command by the system administrator, or in a nightly cron job. In a later kernel release, true online (real-time) dedupe will be added as well.
Automatic GPU switching will be of interest to those using Linux on laptops. Many modern laptop systems feature multiple GPUs (graphics processing units). These are the chips that actually understand OpenGL, and are used to render 3D graphics into the framebuffer that is displayed onto the screen or attached external monitor device. The presence of multiple GPUs allows for a power-optimised unit to provide necessary acceleration for a basic desktop and windowing solution, while a performance-optimised unit can kick in to grind through complex operations – like rendering a massacre in a 3D game sequence. Until now, such switching on Linux required that the machine or X Window server be restarted in order to achieve the switch. 3.12 removes this limitation and allows the graphics subsystem to dynamically switch on demand.
The 3.13 merge window
Prominent features in Linux 3.13 include the new ‘nftables’ packet filter, which will ultimately replace iptables and has been in development
for many years, and Intel’s ‘powercap’ driver, which can allow a sysadmin to impose maximum power consumption limits on peripheral devices (as implemented by Intel’s ‘Running Average Power Limit’ feature in its newer devices). There has also been a fair deal of cleanup going into the kernel’s UEFI support over the past cycle. UEFI is a modern boot mechanism that replaces the legacy PC BIOS in modern systems, including (as of 3.13) some ARM systems. In addition, in 3.13, EFI gains support for using the EFI console as an ‘earlyprintk’ output device, allowing very early system debug messages.
Lesser features appearing in 3.13 include support for ‘Big Endian’ (as opposed to Little Endian being the default) 64- and 32-bit ARM systems, and (not to be outdone) Little Endian support for PowerPC systems (which default to Big Endian). Endianness refers to the way in which a computer understands numbers: Most Significant Byte first, or Least Significant Byte first in multi-byte representations of number systems. Bi-Endianness (being able to switch between modes at runtime) is a common feature on some modern CPU designs because they can run legacy code more easily. Though Little Endian is by far the more common, thanks to its use by the (dominant) x86 and ARM architectures, Big Endian remains very common in network code (hence ‘network order’, which is Big Endian), and in all IBM architectures.
Following his usual practice, Stephen Rothwell posted a link to the stats for his ‘linux-next’ kernel tree after Linus announced 3.12 final. The linux-next tree is used by developers to stabilise new features that will be merged in the next ‘merge window’ that begins a new kernel development cycle. Therefore during Linux 3.12 development the linux-next tree contained features intended to land in 3.13. The graphs nicely show a progression of features from linux-next into Linus’s kernel during the (now closed) 3.13 merge window (and for every kernel back to 3.7). The numbers back up the visual: 82.4% of commits (changes to the kernel) in Linus’s freshly announced 3.13-rc1 were previously in linux-next, while 17.6% did not go directly via linux-next. Those are slightly down on what would be typical (nearer 90% via linux-next) due to the kerfuffle around the week-long delay in opening the 3.13 merge window, which a few people took advantage of.
Jan Kiszka announced the ‘Jailhouse’ partitioning hypervisor from Siemens. This is a new hypervisor that can create asymmetric multiprocessing (AMP) configurations, in which CPUs not being actively used by the Linux kernel for its purposes or to run user applications are partitioned off and used to run entirely different operating systems or applications. Although Linux already has support for isolating CPUs, there was no official framework for managing ‘applications’ running on those cores until now. Jailhouse is in the early stages of development, and is available for download from GitHub.
Andrey Ponomarenko announced the ‘Kernel ABI Tracker’, which “looks for new kernel releases, builds them and tracks API/ABI changes using a set of basic tools: ABI Dumper and ABI Compliance Checker. Such tooling may be of interest to commercial Linux distributions, which often implement stable kernel ABIs intended to allow for external device drivers to be loaded under certain conditions. The tracker website has more .
Jovi Zhangwei announced release 0.3 of the new ‘ktap’ dynamic tracing tool for Linux. Ktap is a bytecode-based tracing infrastructure that allows users to write simple scripts, compiled into bytecode, that are then loaded into a kernel for dynamic instrumentation and tracing of kernel behaviour. As it is not based around compiling code with a specific toolchain (compiler), it doesn’t require that special kernel modules or safeguards are put in place, and is “safe to use in production environment, fulfilling the embedded ecosystem’s tracing needs”. There is a lot of interest in ktap, which was briefly merged into 3.13, but was unmerged before final release. Exactly when ktap will become a standard kernel feature is yet unknown.
Finally, Stefan Kristiansson posted a new VGA/LCD driver for the OpenCores open source framebuffer hardware design. This will allow OpenRISC, and similar open source hardware designs, to provide a video output device that is supported by a standard Linux kernel. If you haven’t played with open Source hardware, take a look at the OpenCores.org and OpenRisc.org websites for more detail.