Features That Didn't Make It For The Mainline Linux 4.18 Kernel

There are many changes and new features for Linux 4.18 with the merge window having just closed on this next kernel version, but still there are some prominent features that have yet to work their way to the mainline tree.

Some of the most prominent work that has yet to be mainlined includes:

Bcachefs - The file-system born out of the block cache code that is promising for offering next-gen Btrfs/ZFS-like features while being performant. Recently the push began for getting Bcachefs mainlined but the file-system itself hasn't been merged for Linux 4.18, hopefully we will see it by 4.19 or 5.0. A few weeks back I delivered some updated Bcachefs Linux file-system benchmarks using the latest out-of-tree module.

NOVA - Another file-system not yet mainlined is NOVA that is being developed by the talented folks at UC San Diego for persistent memory. NOVA is being actively developed but at least as of yet doesn't seem ready for the mainline tree.

Reiser4 - While on the topic of file-systems, we can't help but wonder if Reiser4 will ever be mainlined... This files-system made infamous due to being started by convicted killer Hans Reiser is still being maintained out-of-tree by the few developers left involved with the effort, but currently doesn't have the backing of any major organization to see it through in getting mainlined. At this stage, Reiser4 seems to have as little chance as getting into the official kernel tree as ZFS on Linux.

WireGuard - The WireGuard in-kernel VPN tunnel continues to be developed and is a highly promising effort. WireGuard is looking to go mainline this calendar year but hasn't yet attempted to do so, but hopefully we'll see that still pan out soon.

LLVMLinux / Clang'ing The Kernel - The effort seems to have stalled a bit around building the Linux kernel with the LLVM/Clang compiler rather than GCC. It seems to be pretty much there for ARM/ARM64 platforms, but not many patches lately on the x86_64 side for getting it over the finish line for getting the mainline Clang compiler to be able to build an optimized mainline Linux kernel build.

BUS1 - The BUS1 in-kernel IPC implementation still is being developed, at least well sort of. The BUS1 out-of-tree kernel module hasn't seen any commits to its repository in a few months. BUS1 was born out of the KDBUS implementation not getting traction for going mainline as an in-kernel D-Bus implementation. Lately the BUS1 developers appear more focused on their Dbus-Broker D-Bus compatible high-performance implementation.

OpenChrome / VIA DRM - The sole developer left working on this open-source VIA Direct Rendering Manager driver recently tried getting the driver mainlined but that didn't pan out yet. Now that developer decided to take a break and is going to try improving the ATI Rage driver support. It's unclear if/when this long in development OpenChrome VIA DRM driver will be mainlined.

i.MX8 - There was talk of seeing mainline support for the new-ish i.MX8 SoC around Linux 4.17~4.18 and while some code has landed around SATA support and some Etnaviv DRM bits, the full SoC support has not. Why this is important/interesting is that the i.MX8 SoC is going to be used by the Purism Librem 5 smart-phone. Hopefully this SoC support will get squared away for Linux 4.19 as what will be the last kernel release of 2018 so that by the time the phone is shipping in January it could run with a mainline kernel and thereby making it easier to spin up other software stacks around the device.

Nouveau Re-Clocking - There wasn't any magical event to happen and thus the open-source NVIDIA DRM driver still can't re-clock Pascal/Maxwell graphics processors... A.k.a. terribly slow performance still until the Nouveau developers manage to find a way to workaround the signed firmware blobs or NVIDIA releases documentation / PMU firmware. See my recent Nouveau driver status for the summer of 2018 for more on the current state of this open-source NVIDIA driver.

FreeSync / AdaptiveSync - We are still waiting for the open-source DRM drivers to get over the last mile for FreeSync/AdaptiveSync. While the AMDGPU Display Code "DC" stack is mainlined and enabled by default, the developers are still waiting/working-on (we haven't seen much activity since April) in coming up with a FreeSync/AdaptiveSync API that could be used across the different Linux DRM drivers. The last discussion was documented here and unfortunately haven't seen anything happen since for allowing the open-source Linux desktop support these variable rate refresh technologies.

Anything else you would like to see in the mainline kernel or other prominent material that didn't get mainlined for Linux 4.18? Let us know in the forums.