Linux 5.1 has not been released.

Summary: TBD

(Note: in this release, the "coolest features" section does not have links to the code commits, those are available for each feature in their respective sections, preceded by FEATURED)

1. Coolest features

1.1. High-performance asynchronous I/O with io_uring

Linux has had an asynchronous I/O interface for a long time. However, that interface has historically suffered from a large number of shortcomings. It does not support buffered I/O, only synchronous (O_DIRECT) I/O, which only a subset of a subset of applications use. Even in those cases asynchronous IO was some times not really asynchronous or fast. All attempts to fix the existing interface have failed.

A new asynchronous interface, io_uring, has been created and merged in the release, with the purpose of finally bringing usable asynchronous I/O to Linux. io_uring supports fast, scalable synchronous I/O, both buffered and unbuffered, and it supports asynchronous polled IO. For more details, read this document (PDF) that explains the reasons for the existence of io_uring, inner workings of it, and the user visible interface. For performance details, see this email.

Additionally, a user space library (liburing) has been created to provides basic functionality for applications that don't need or want to care about how to fiddle with the low level details of the kernel interface. It has helpers to allow applications to easily set up an io_uring instance, and submit/complete IO through it without knowing about the intricacies of the rings, and will continue to grow support helper functions and features as time progresses.

Document explaining the reasons for the existence of io_uring, inner workings of it, and the user visible interface: io_uring.pdf

Recommended LWN article: Ringing in a new asynchronous I/O API

Git liburing repository:

1.2. Improved fanotify for better file system monitorization

Linux did not have a good way to watch changes on a large file system. The only way to monitor file system dirent modification events was using recursive inotify watches, and this method scales very poorly for large directory trees. The fanotify interface, introduced in Linux 2.6.36, intended to supersede inotify and solve its deficiencies, and it initially took several steps in the direction of solving the inotify scalability issues. But it did not go all the way to provide the functionality required to replace inotify and provide Linux with a good file system notification interface.

This release (along with the patches added in Linux 4.20) expands fanotify to provide "super block root watch" funcionality. The end game is to use: fd = fanotify_init(FAN_CLASS_NOTIF|FAN_REPORT_FID, ...); rc = fanotify_mark(fd, FAN_MARK_FILESYSTEM, FAN_CREATE|FAN_DELETE...); to monitor changes to a large scale. For more details see the project wiki

1.3. Safe signal delivery to dead processes

The kill(2) syscall operates on PIDs. After a process has exited its PID can be reused by another process. If a caller sends a signal to a reused PID it will end up signaling the wrong process. This is an old problem with the Unix process design, and has caused numerous security problems.

After considering several proposals, the Linux kernel has added a new syscall, pidfd_send_signal(2), which uses file descriptors from /proc/<pid> as stable handles on struct pid. Even if a pid is recycled the handle will not change, and the file descriptor can be used to safely send signals to the process it refers to.

Recommended LWN article: Toward race-free process signaling

asciinema recording for the basic functionality:

1.4. Use persistent memory as RAM

Linux supports persisten memory devices, but they are often used as storage devices. Some users want to use persistent memory as additional volatile memory, they are willing to cope with potential performance differences, and want to use typical Linux memory management apis rather than a userspace memory allocator layered over an mmap() of a dax file. This release allows them to do so. This is intended for use with NVDIMMs that are physically persistent (physically like flash) so that they can be used as a cost-effective RAM replacement.

Recommended LWN article: Persistent memory for transient data

1.5. TEO, an alternative cpuidle governor to 'menu'

The cpuidle subsystem is the part of the kernel in charge of deciding which CPU deep idle state should be used when the CPU has nothing to do (deeper idle states save more power, but it takes more time to get out of them). There are two cpuidle governors, "menu" and "ladder", each one using different heuristics (which one, can be checked in /sys/devices/system/cpu/cpuidle/current_governor_ro). However, the menu governor is believed to have a number of shortcomings in its heuristics, but instead of being fixed an alternative was introduced in this release so people can compare both: TEO, the Timer Events Oriented Governor, which seems to offer improved performance with no extra power consumption cost. You can change the default cpuidle governor with the cpuidle.governor=teo boot parameter.

Recommended LWN article: Improving idle behavior in tickless systems

1.6. More Year 2038 preparation

As part of the work to prepare for the prepare for the year 2038 problem, this release includes syscalls for 32 bits architecture with a 64-bit time_t structure. This finally allows to have system calls with 64-bit time_t on all architectures, after a long time of preparation

Recommended LWN article: Approaching the kernel year-2038 end game

1.7. Configurable Zstd compression level in Btrfs

Btrfs has support Zstd compression since Linuz 4.14, but it didn't allow to configure the compression level used by the filesystem, which can make a big difference. This release adds support for configuring the compression level used in a Btrfs file system, as it's done with zlib, by using the mount option -o compress=zstd:level. To see the levels available and their impact in performance and compression rate, see this commit

1.8. Boot to a device-mapper device without initramfs

In order to boot to a filesystem placed in a device-mapper array, you usually need an initramfs. Some people, however, don't want or can't use an initramfs. This release allows to use of DM targets in the boot process (as the root device or otherwise) without the need of an initramfs, with the help of a tricky kernel boot parameter. For more details see the documentation

2. Core (various)

3. File systems

4. Memory management

5. Block layer

6. Tracing and perf

7. Security

8. Networking

9. Architectures

10. Drivers

10.1. Graphics

10.2. Storage

10.3. Drivers in the Staging area

10.4. Networking

10.5. Audio

10.6. Tablets, touch screens, keyboards, mouses

10.7. TV tuners, webcams, video capturers

10.8. Universal Serial Bus

10.9. Serial Peripheral Interface (SPI)

10.10. Watchdog

10.11. Serial

10.12. ACPI, EFI, cpufreq, thermal, Power Management

10.13. Real Time Clock (RTC)

10.14. Voltage, current regulators, power capping, power supply

10.15. Pin Controllers (pinctrl)

10.16. Multi Media Card (MMC)

10.17. Memory Technology Devices (MTD)

10.18. Industrial I/O (iio)

10.19. Multi Function Devices (MFD)

10.20. Pulse-Width Modulation (PWM)

10.21. Inter-Integrated Circuit (I2C)

10.22. Hardware monitoring (hwmon)

10.23. General Purpose I/O (gpio)

10.24. DMA engines

10.25. Hardware Random Number Generator (hwrng)

10.26. Cryptography hardware acceleration

10.27. PCI

10.28. Clock

10.29. EDAC (Error Detection And Correction)

10.30. PHY ("physical layer" framework)

10.31. Various

11. List of merges

12. Other news sites

KernelNewbies: Linux_5.1 (last edited 2019-05-03 22:20:52 by diegocalleja)