What's coming in the next kernel release (part 1)
Some of the more significant changes merged so far are:
Architecture-specific
- Intel's processor trace functionality is now supported for use by virtualized guests running under KVM.
- The arm64 architecture has gained support for a number of features including the kexec_file_load() system call, 52-bit virtual address support for user space, hotpluggable memory, per-thread stack canaries, and pointer authentication (for user space only at this point). This commit has some documentation for the pointer-authentication feature.
Core kernel
- The long-awaited energy-aware scheduling patches have finally found their way into the mainline. This code adds a new energy model that allows the scheduler to determine what the relative power cost of scheduling decisions will be. It will enable the mainline scheduler to get better results on mobile devices and, with luck, reduce or eliminate the scheduler patching that various vendors engage in now.
- 64-Bit versions of the ppoll(), pselect6(),
io_pgetevents(), recvmmsg(), futex(), and
rt_sigtimedwait() system calls have been added for 32-bit
systems, making it possible to use these calls successfully after the
year-2038 apocalypse. This completes the set of top-level system call
conversions. According
to Arnd Bergmann: "
Hopefully in the next release we can wire up all 22 of those system calls on all 32-bit architectures, which gives us a baseline version for glibc to start using them
". - The cpuset controller now works (with reduced features) under the version-2 control-group API. See the documentation updates in this commit for details.
Filesystems and block layer
- The Btrfs filesystem has regained the ability to host swap files, though with a lot of limitations (no copy-on-write, must be stored on a single device, and no compression allowed, for example).
- The fanotify() mechanism supports a new FAN_OPEN_EXEC request to receive notifications when a file is opened to be executed.
- The legacy (non-multiqueue) block layer code has been removed, now that no drivers require it. The legacy I/O schedulers (including CFQ and deadline) have been removed as well.
- "Binderfs" is a new virtual filesystem used to control the Android binder subsystem. See this commit for some information.
Hardware support
- Audio: AKM AK4118 S/PDIF transceivers, Amlogic AXG SPDIF inputs, Xilinx I2S audio interfaces, and Cirrus Logic CS47L35/85/90/91 and WM1840 codecs.
- Graphics: Olimex LCD-OLinuXino bridge panels, Samsung S6D16D0 DSI video mode panels, Truly NT35597 WQXGA dual DSI video mode panels, and Himax HX8357D LCD controllers.
- I3C: The kernel has a new subsystem for I3C devices, along with drivers for Cadence and Synopsys DesignWare controllers.
- Industrial I/O: Analog Devices AD7949 and AD7124 analog-to-digital converters, Texas Instruments DAC7311, DAC6311, and DAC5311 digital-to-analog converters, Vishay VCNL4035 light and proximity sensors, PNI RM3100 3-Axis magnetometers, and Microchip MCP41xxx/MCP42xxx digital potentiometers.
- Media: Sony IMX214 sensors, SECO Boards HDMI CEC interfaces, Allwinner V3s camera sensor interfaces, Rockchip VPU JPEG encoders, Aspeed AST2400 and AST2500 video engines, and Intel ipu3-imgu image processing units.
- Miscellaneous: Microchip MCP16502 power-management ICs, Macronix MX25F0A SPI controllers, Nuvoton NPCM peripheral SPI controllers, Cavium ThunderX2 SoC uncore PMUs, Alcor Micro AU6601 and AU6621 SD/MMC controllers, TI AM654 SDHCI controllers, Cadence GPIO controllers, Microchip SAMA5D1 PIOBU GPIO controllers, Spreadtrum SC27XX fuel gauges, and Intel Stratix10 SoC FPGA managers.
- Networking: Aquantia AQtion 5/2.5GbE USB network interfaces, Quantenna QSR1000/QSR2000 wireless network interfaces, and MediaTek GMAC Ethernet controllers.
- USB: Cadence Sierra USB PHYs and Freescale i.MX8M USB3 PHYs.
Networking
- Generic receive offload (GRO) can now be enabled on plain UDP sockets. If the numbers in this commit are to be believed, the result is a significant increase in receive bandwidth and a large reduction in the number of system calls required.
- ICMP error handling for UDP tunnels is now supported.
- The MSG_ZEROCOPY option is now supported for UDP sockets.
Security
- Support for the Streebog hash function (also known as GOST R 34.11-2012) has been added to the cryptographic subsystem.
- A new crypto mode called "Adiantum" has been added as a replacement for the (removed) Speck algorithm. Adiantum is intended to be secure while being fast enough to perform disk encryption on low-end handsets; see this commit message for details. As part of this work, support for the XChaCha12 and XChaCha20 stream ciphers was also added.
- The kernel is now able to support non-volatile memory arrays with built-in security features; see Documentation/nvdimm/security.txt for details.
Internal kernel changes
- There is a new "software node" concept that is meant to be analogous to the "firmware nodes" created in ACPI or device-tree descriptions. See this commit for some additional information.
- The first two of the retpoline-elimination mechanisms described in this article have been merged. improving performance in core parts of the DMA mapping and networking layers.
- The software-tag-based mode for KASAN has been added for the arm64 architecture.
- The switch to using JSON schemas for device-tree bindings has begun with the merging of the core infrastructure and the conversion of a number of binding files.
- The long-deprecated SUBDIRS= build option is finally going away in the 5.3 merge window; users will start seeing a warning as of 5.0. The M= option should be used instead.
Before the 4.20 release, Torvalds had suggested that this merge window
would go for longer than usual given the presence of the holidays in the
middle. The pace of merging so far suggests that this plan has fallen by
the wayside,
though, and maintainers should not count on the merge window being open
past January 6. As always, LWN will follow up with a summary of the
changes that are merged between now and the closing of the merge window,
whenever that may be.
Index entries for this article | |
---|---|
Kernel | Releases/5.0 |
Posted Dec 31, 2018 19:48 UTC (Mon)
by pbonzini (subscriber, #60935)
[Link]
Posted Dec 31, 2018 23:08 UTC (Mon)
by gerdesj (subscriber, #5446)
[Link] (2 responses)
Posted Dec 31, 2018 23:25 UTC (Mon)
by gerdesj (subscriber, #5446)
[Link] (1 responses)
Cool! This is one of those high level stats that gets you started on fixing problems.
(https://lwn.net/Articles/759781/)
Posted Jan 1, 2019 20:28 UTC (Tue)
by flussence (guest, #85566)
[Link]
Posted Jan 1, 2019 14:19 UTC (Tue)
by nilsmeyer (guest, #122604)
[Link] (1 responses)
Posted Jan 1, 2019 14:46 UTC (Tue)
by Margaret48 (guest, #129042)
[Link]
Posted Jan 8, 2019 2:24 UTC (Tue)
by ghane (guest, #1805)
[Link]
:-)
--
What's coming in the next kernel release (part 1)
What's coming in the next kernel release (part 1)
What's coming in the next kernel release (part 1)
some avg10=0.00 avg60=0.03 avg300=0.07 total=872753
I get unusually high numbers on mine, probably an allergic reaction to MuQSS as the system's usually idle and responsive.
What's coming in the next kernel release (part 1)
~ $ head /proc/pressure/*
==> /proc/pressure/cpu <==
some avg10=98.54 avg60=91.98 avg300=91.54 total=54064616695
==> /proc/pressure/io <==
some avg10=0.00 avg60=0.04 avg300=0.14 total=209725857
full avg10=0.00 avg60=0.00 avg300=0.00 total=1176
==> /proc/pressure/memory <==
some avg10=98.54 avg60=91.98 avg300=91.54 total=38856432564
full avg10=0.00 avg60=0.00 avg300=0.00 total=5130852
What's coming in the next kernel release (part 1)
What's coming in the next kernel release (part 1)
What's coming in the next kernel release (part 1)
> We did find that some "lightweight" block ciphers are fast enough, but these suffer from problems such as not having much cryptanalysis or being too controversial.
Sanjeev