The 3.20 merge window opens

The 3.20 merge window opened on February 8 with the release of the 3.19 kernel. Since then, as of this writing, just over 3600 non-merge changesets have been pulled into the mainline repository. Some of the more interesting, user-visible changes pulled so far include:

• The core of a new live-patching mechanism has been merged. This core is meant to support both kGraft and kpatch, though additional work will be required to get there. Meanwhile, what the kernel has now is enough to support the live application of simple security patches. See this merge commit for some more information or this commit for an example of a simple live patch.

• The kernel can be built to run read-copy-update (RCU) grace-period-handling threads at realtime priorities. Most systems do not need this, but some heavy workloads can benefit from this feature.

• As was threatened last year, the implementation of the remap_file_pages() system call has been removed. In its place is a function that emulates the same functionality using multiple virtual memory areas, so the (few) applications using this call should continue to work.

• The perf tool has seen the usual range of improvements; see the changelog on this merge commit for the list.

• The network stack can now support the application of specific congestion-control algorithms on a per-host basis via the routing table. This patch includes documentation updates showing how the new ip route commands work.

• The network stack's TIPC implementation is now namespace-aware.

• The traffic control subsystem now supports the application of filters written in the eBPF virtual machine language.

• The Open vSwitch subsystem can now generate its own "flow IDs" to identify network streams in user-space command traffic. This change, it is said, can improve performance of some operations by 40%.

• New hardware support includes:
  • Audio: Studio Evolution SE6X sound cards, Intel Cherrytrail and Braswell systems with RT5645 codecs, and NVIDIA Tegra boards with RT5677 codecs.

  • Input: Betop Production Inc. force-feedback devices, Allwinner sun4i tablet keys, TI TPS65218 power buttons, X-Powers AXP20X power buttons, NI Ettus Research USRP E3x0 Buttons, and Allwinner A10 PS/2 controllers.

  • Miscellaneous: Diolan DLN2 USB-SPI adapters, STMicroelectronics SSC-driven SPI controllers, Maxim 77843 regulators, MediaTek MT6397 PMIC regulators, Synopsys DDR memory controllers, Fujitsu Semiconductor F_SDH30 SDHCI controllers, Richtek RT5033 battery fuel gauges, Maxim MAX77693 battery chargers, LTC2941/LTC2943 battery gauges, and TI OMAP OPA362 external analog amplifiers.

  • Networking: Rockchip SoC RK3288 10/100/1000 Ethernet controllers, HISILICON P04 Ethernet controllers, TI Keystone NETCP Ethernet subsystems, Kvaser USBcan II CAN interfaces, and PEAK PCAN-USB/USB Pro CAN-FD interfaces.

  • SCSI: Qualcomm UFS PHYs.

  • Video4Linux: TI AM437x VPFE video capture devices, Philips RC5/RC6 decoders, and Touptek USB cameras.

Changes visible to kernel developers include:

• The sleepable read-copy-update subsystem can be compiled out of the kernel to free up some space on tiny systems where it may not be needed.

• The might_sleep() debugging function will now check for stack overflows if things look wrong. It seems that, often, what looks like an inappropriate call to a sleeping function is actually an artifact caused by a stack overflow.

• The new devfreq_event mechanism provides a way for device power-management governors to get raw data on device performance and utilization.

There are a couple of things worth keeping in mind with regard to the rest of this merge window. One is that, according to linux-next maintainer Stephen Rothwell, this release may be the smallest in some time. The linux-next repository peaked out at just over 8,000 changesets; pre-3.19 linux-next had almost 11,000. So this could end up being a relatively quiet cycle overall.

The other is that there is still a possibility that the resulting kernel might not be called 3.20. Back in 2013, Linus had suggested that the kernel coming after 3.19 might be called 4.0. As with the 3.0 bump, this change would have no particular meaning; it's just that Linus doesn't want to return to "release numbers where I have to take off my socks to count that high again". He has said nothing recently about going to 4.0, but that change could happen anytime in the next few weeks. Stay tuned.

Index entries for this article
Kernel	Releases/4.0

---

to post comments