The 4.1 merge window closes

By the time Linus released 4.1-rc1 and closed the merge window for this development cycle, some 10,659 non-merge changesets had been pulled into the mainline repository. That makes 4.1 a reasonably busy development cycle, but far from the busiest; 3.19 had 11,400 changes during the merge window, and 3.15, the record holder, had just over 12,000. Even if 4.1 is not a record breaker, though, anybody who worried that 4.0 signaled a general slowdown in kernel development can rest easier now.

Only about 900 of those changesets were pulled since last week's summary, but there were some interesting changes buried in that last batch. Some of the more significant, user-visible changes include:

• The XFS filesystem has gained RENAME_WHITEOUT support, meaning that it should now work with the overlayfs union filesystem. Also new in XFS is support for the FALLOC_FL_INSERT_RANGE option to fallocate(), allowing applications to insert a hole into a file.

• The Btrfs filesystem has seen some important fixes, though they may not be hugely relevant for many users: they apply to filesystems 20TB and larger or to individual files that are 3TB or larger.

• The virtio subsystem has a new virtio-input driver; its job is to collect and forward input-device events to a virtual device.

• The arm64 architecture has gained support for the Advanced Configuration and Power Interface, otherwise known as ACPI. Supporting ACPI for ARM has been controversial in the past; many developers would rather see the device tree mechanism used universally for hardware discovery on that architecture. The addition of ACPI happened quietly in the end, though, and it seems likely that there will be servers using ACPI shipping in the near future. That said, there is still some work to do; the merge commit notes that "we don't support any peripherals yet, so it's fairly limited in scope." See Documentation/arm64/arm-acpi.txt for a lot of information about ACPI on ARM.

• The MD (RAID) subsystem can now manage RAID 1 arrays in a distributed fashion across a cluster. This code is currently marked as being experimental, but it is evidently nearing a production-ready state.

• New hardware support includes:
  • DMA: Ingenic JZ4780 DMA controllers, Renesas USB-DMA controllers, Applied Micro X-Gene SoC DMA engines, and Freescale RAID engines.

  • Miscellaneous: ChromeOS embedded controllers, ChromeOS "lightbar" devices, and Dell keyboard backlights.

Changes visible to kernel developers include:

• The "exception table" lists locations in the kernel that might generate faulting address references; in essence, the table contains a list of every invocation of copy_*_user() and related functions. When a fault happens in kernel mode, this table is consulted to see whether the fault was expected or not. This mechanism allows the kernel to safely access user-space data without having to explicitly check each pointer before dereferencing it.

  Each loadable module has an exception table of its own to mark such invocations. As of 4.1, the module loader will actively check to ensure that every exception-table entry points to a location within the module's executable text. Any entry not pointing to a known text section must be erroneous, but evidently they come up, especially in situations where a new executable section is being added to the kernel. Developers will want to watch out for this new type of failure, especially when working on the less-mainstream architectures.

One thing that did not get merged this time around was the kdbus interprocess communication system. Linus did not comment on his decision to leave it out, but it seems clear that this code was too controversial to be pulled straight into the mainline. Now both the supporters of kdbus and those who are concerned about aspects of its design have another development cycle to discuss the issues, and, hopefully, come to some sort of conclusion that allows kdbus to proceed.

Meanwhile, the 4.1 kernel is now in the stabilization phase of the development cycle. If things follow the recent pattern, the final 4.1 kernel release will happen on June 14.

Index entries for this article
Kernel	Releases/4.1

---

to post comments