As we were going to press, Linus Torvalds announced the 3.16 Linux kernel, saying “So nothing particularly exciting happened this week [since the final 3.16 Release Candidate 7 from a week prior], and 3.16 is out there.” In his announcement email, Linus noted that the timing of 3.16 was, perhaps, a little unfortunate for the impact upon the merge widow for 3.17. The “merge window” is the period of time early in a (roughly) two month kernel development cycle during which disruptive kernel changes are allowed to take place. Typically, the merge window is capped at a couple of weeks, and it immediately follows a final release (from the previous kernel development cycle). Therefore, the merge for 3.17 is open just as Linus (and others) are preparing to head to Chicago for the 2014 Kernel Summit (and LinuxCon conference). Linus says, “So we’ll see how the next merge window goes, but I’m not going to worry about it overmuch. If I end up not having time to do all the merges, I might delay things into the week of the Kernel Summit, but I’ll hope to get most of the big merging done this upcoming week before any travel takes place.”
Linus had been concerned for a few weeks that Linux 3.16 “looked a bit iffy for a while,” chiefly because of the amount of late-in-cycle code churn that was taking place. By the time we got to 3.16-rc6, Linus was sounding the alarm, saying “Week by week, we’re getting to what is supposed to be the last rcs, but quite frankly, things aren’t calming down the way they are supposed to”. He then noted how RC5 had been larger than RC4, and RC6 was still larger than RC5 had been. “That’s not how this is all supposed to work,” said Linus. Nevertheless, by the time 3.16 final rolled around, Linus was less alarmed and thought that things had “cleared up nicely,” just as he was beginning to fear that additional stabililising RCs might have been (unusually) necessary. It is possible that this will combine with the fears around a merge window for 3.17 happening during Kernel Summit to mean that he is even more cautious in this next kernel cycle around such code churn.
Linux 3.16 brings with it a number of new features. Unlike in many recent development cycles, these new features are more “internal” – and aimed towards developers – than they are new earth-shattering features for end users. For example, the kernel’s earlyprintk diagnostic output support has been reworked into the newly generic “earlycon” interface, and a number of block IO subsystem components have been moved into the kernel’s block/ directory (to more clearly show maintainership, without any changes to the code itself). End user visible changes of note include support for UEFI boot firmware on the ARM64 (AArch64) 64-bit ARM Architecture, which will be particularly important for the coming wave of industry standard ARM servers, which will all boot using this method.
Early kernel logging
The newly reworked “earlycon” kernel mechanism in 3.16 generifies the existing in-kernel “earlyprintk” mechanism across architectures. Early printk is a mechanism that allows the kernel to output diagnostic information (including the famous kernel_banner that includes the version number) early during the boot process, before the regular facilities for kernel logging have fully come online. Historically, each architecture implemented things a little differently. For example, the 64-bit ARM Architecture – known as arm64 to the kernel – used a simple driver that was registered during early_param parsing within the kernel boot cycle (after running setup_arch, but before doing a lot more than getting the basic Virtual Memory subsystem up and running). The ARM kernel would look for a kernel command line option of “early_printk=” that would include the address of a serial port UART controller, as well as its type, to which the kernel would log messages before it had properly initialized its serial console.
Those booting without special early_printk options would still get to see boot messages, but they would be buffered and displayed later in the boot process, once the standard infrastracture for logging was online. The user would unlikely notice the difference as many systems don’t display these messages by default, and the buffering would only delay output by less than a second in any case, but during that crucial second, many other things could have gone wrong that kernel developers would care about in debugging critical kernel issues. The new kernel infrastructure for diagnostic logging is known as “earlycon” and it replaces the boot parameter with the same name. As an aside, specifications such as ACPI allow for a diagnostic console to be defined by a system vendor, and it is hoped that systems such as PCs will be able to automatically use this information in the future.
Ted Ts’o (original author of ext2fs, ext3fs, ext4fs) posted an RFC (Request For Comment) patch entitled “random: introduce getrandom(2) system call,” which introduces a new kernel interface for providing applications with random numbers. “But why,” you may ask, “is such a new interface being introduced now, especially as the kernel has long had support for the generation of random numbers through reading the /dev/random and / dev/urandom special kernel files?” The problem lies in how these files operate. Because they must be opened by an application requiring random numbers, it is possible for an attacker to arrange that all available file descriptors (one is used per open file) are exhausted immediately prior to a system security daemon (like the OpenSSH remote login software) requiring the use of random numbers for an SSH (or SSL, etc.) protocol handshake. By exhausting all available file descriptors (fds), an attacker can make it hard for such software to function (or generate weak random numbers, and compromise the ability to provide a secure environment). The new API instead works through a system call, as on BSD.
John Stulz and Rafael Wysocki discussed a patch previously posted by Ruchi Kandoi (of Google) that would provide an interface within the kernel’s sysfs hierarchy (under /sys/kernel/ wakeup_reasons/last_resume_reason) informing the user (or software developer) of the reason for the last kernel wakeup from a low power state. This is important on mobile devices where the goal is to remain in a low-power state for long periods of time between bursts of activity, as it is hoped that management software can capture the effects of bugs or errant apps causing extra drain upon the user’s battery life and phone using experience.
Prabhakar Kushwaha, Tanmay Inamar, and Liviu Dudau (of ARM) discussed the requirements for PCIe support on the 64-bit ARM Architecture known to the kernel as “arm64”. Liviu Dudau has posted some generic patches which rely upon system boot firmware (such as UEFI) to have correctly configured various hidden platform specifics before booting the kernel proper. This is similar to platforms such as x86 PCs, but differs from how many embedded devices are configured. Nonetheless, there is a general push to adopt UEFI across the board on arm64, and this was conveyed in the replies, which noted that there would not be an emphasis on supporting non-UEFI here.
A number of kernel developers debated the presence of the words “Copyright,” followed by “All Rights Reserved” in the upstream kernel. According to Paul Bolle, who used the “git” source code management system command “git grep -i” to search for matching lines of kernel source code, there were 5203 instances of this in Linux 3.16-rc3. Greg Kroah-Hartman (of the Linux Foundation) responded that “I used to be ‘worried’ about that as well, turns out it means nothing”. According to Greg, “It’s the license of the code that is the issue, not the copyright line, which all lawyers tell me now shouldn’t even be in a file, as it again means nothing”. This is interesting to know.
Finally this month, the Linux Foundation posted a “rare look inside” Linus Torvalds’ home office, in the form of a YouTube video that showcases his newly installed tread desk. The video featuring Linus is online on YouTube.