The end of the 5.5 merge window
Architecture-specific
- The RISC-V architecture has gained support for the seccomp() system call (including filtering with BPF).
- RISC-V systems without a memory-management unit are now supported.
- The xtensa architecture can now boot from execute-in-place kernels.
Core kernel
- The new IORING_OP_CONNECT command for io_uring allows connect() calls to be performed asynchronously.
- After years of deprecation, the sysctl() system call has been removed.
- Synthetic trace events can be created with the new injection mechanism. The use case appears to be testing of software that reacts to trace events.
Filesystems and block I/O
- The XFS "iomap" code has been moved into into the virtual filesystem layer, making this infrastructure available to other filesystems. The ext4 filesystem has been modified to use this code. The end result is simpler, more consistent, and hopefully less buggy direct I/O in a number of filesystems.
- The CIFS filesystem now supports the flock() system call. CIFS has also gained multichannel support, which should improve performance.
- The hugetlbfs filesystem now supports creating files with the O_TMPFILE option.
- The NFS client has gained support for cross-device offloaded copy operations — copying a file directly from one remote server to another.
Hardware support
- Clock: Qualcomm QCS404 Q6SSTOP clock controllers, Qualcomm SC7180 global clock controllers, Qualcomm MSM8998 graphics clock controllers, Ingenic X1000 clock generators, and Bitmain BM1880 clock controllers.
- DMA: NXP DPAA2 QDMA controllers, Milbeaut AHB and AXI DMA controllers, and Sifive PDMA controllers.
- Miscellaneous: Crane EL15203000 LED controllers, RDA Micro GPIO controllers, Broadcom XGS iProc GPIO controllers, Mellanox BlueField firmware boot control units, Amlogic G12 thermal sensors, Samsung EXYNOS5422 dynamic memory controllers, Qualcomm on-chip memory controllers, Marvell MMP3 USB PHYs, and NVIDIA Tegra30 external memory controllers.
Security-related
- The seccomp() user-space notification mechanism has gained a new return code, SECCOMP_USER_NOTIF_FLAG_CONTINUE, which instructs the kernel to allow the system call in question to continue executing.
Internal kernel changes
- It is now possible for kernel subsystems to set up their own tracing instances without worrying about interfering with any tracing done from user space.
- The DMA-BUF heaps subsystem — meant to serve as a replacement for the Android-specific ION allocator — was merged but then reverted. It seems that it lacks a demonstrated open-source user-space user as required by the DRM subsystem. This feature will probably have to wait for 5.6.
- Most of the ioctl() compatibility code has been pushed out into the drivers that need it; this code should disappear entirely in the relatively near future.
- Code-testing coverage with kcov can now monitor execution by background kernel threads. Some special annotation is required; see this commit for details.
One item that (as expected) did not make it into 5.5 is the WireGuard virtual private network system. That
long-awaited feature is coming soon, though: it has already
been merged into the networking tree for the 5.6 release.
Meanwhile, the 5.5 kernel is now in the stabilization period where, with
luck, all of
the new bugs will be fixed. The final 5.5 release can be expected around
the beginning of February 2020.
Index entries for this article | |
---|---|
Kernel | Releases/5.5 |
Posted Dec 9, 2019 21:20 UTC (Mon)
by dgc (subscriber, #6611)
[Link]
> The XFS "iomap" code has been moved into into the virtual filesystem layer, [...] The ext4 filesystem has been modified to use this code.
Large parts of the iomap IO infrastructure has been in the VFS (as fs/iomap.c) for a long time. e.g. FSDAX uses the generic VFS iomap infrastructure and ext4 already uses that. What went into the 5.5 kernel was the final piece that allows implementing entire filesystems on iomap without needing to write special filesystem code: a generic, fully functional buffered writeback path.
IOWs, the ext4 port to the iomap direct IO infrastructure is not related at all to the lifting of the iomap buffered writeback path out of XFS - they just happened to land in the same merge window....
-Dave.
The end of the 5.5 merge window