Where The Linux 3.3 Kernel Will Come Up Short

While there's a lot of improvements in the Linux 3.3 kernel, it's not perfect. Here's some of what's unfortunately missing from this forthcoming kernel.

First of all, among the "great stuff" being introduced in the Linux 3.3 kernel is Btrfs and EXT4 file-system improvements, ACPI 5.0 support and other improvements, many staging changes, Byte Queue Limitsimproved Ivy Bridge support, many open-source graphics improvements, and the fix for the notorious ASPM power regression, among hundreds of other Git commits. With Linux 3.3, the kernel is weighing in at over 15 million lines of code.

Now that the Linux 3.3-rc1 kernel has been released this week, we can look at what didn't make the cut for this next major Linux kernel release. Many of the changes shouldn't come as a surprise if you've been keeping up to date on Phoronix content, as much of this information is covered individually in other articles, but here's a concise overview of some missing functionality.

- There's still not any mainline VIA kernel mode-setting support. James Simmons has been independently working on this code for more than one year, he has made great headway and it's working for many systems, but it's still not ready for mainline integration. Hopefully later this year the support will land for the unfortunate few users of VIA hardware.

- There's not any open-source Radeon HD 7000 series "Southern Islands" (SI) support. Right now Linux users are bound to the AMD Catalyst Linux driver. With the Linux 3.3 kernel there are some underlying changes like Radeon VM and other work that will ultimately benefit the Radeon DRM hardware enablement of this latest-generation of Radeon hardware, but it's not in a state yet for end-users. As this is new hardware support it's possible the initial code drop could occur later in the 3.3 cycle if no other changes are needed that could potentially impair (cause regressions) for previous generations of Radeon ASICs, but there's no indication right now AMD is ready or able to push out this code in time for the 3.3 release.

- AMD's other Radeon priorities are still being addressed, including OpenCL and UVD video support. These are both long-term work items. On the DRM side, R600 2D color tiling still isn't ready.

- Intel RC6 by default still hasn't been figured out fully by Intel for the logic when it can be successfully enabled without causing issues. This is for Intel Sandy Bridge hardware, but at least for the next-generation Ivy Bridge it looks like it can be more safely handled without causing issues for a minority of users. RC6-by-default has been an ongoing headache for Intel.

- Nouveau is still a mess in terms of properly doing re-clocking and other features on the latest generations of NVIDIA GeForce hardware. The Linux 3.4 kernel should have some interesting improvements in the Nouveau-land.

- There's no accelerated Medfield (or Intel Poulsbo) open-source support, but just the basic DRM/KMS driver that doesn't do too much beyond mode-setting.

- the Linux I/O scheduler for flash/SSD drives is still a work-in-progress not ready for mainline.

- There's still no interest in mainlining the Reiser4 file-system. I'm beginning to wonder if Reiser4 will ever see it to the mainline kernel tree of Linus Torvalds. The current out-of-tree patches for Reiser4 also aren't up-to-date against the latest Linux kernel releases due to a number of in-kernel VFS changes and other work. Edward Shishkin continues to be the principal developer of this work in his spare time.

- The DRM Virtual GEM Provider isn't in the mainline tree right now. This "fake" driver is what will speed-up LLVMpipe and other software-based graphics driver implementations. While not in the mainline tree, we might see this early work in Fedora 17 since that's the first major Linux distribution where they're hoping to use the GNOME Shell everywhere, which means a decent LLVMpipe experience for running the Mutter composited window manager on the CPU should you not have a supported graphics card / driver.

- Frontswap still isn't ready as a mainline complement to the Cleancache technology, which was previously merged into the tree.

- Btrfs Snappy compression has made it into the Btrfs tree of Chris Wilson, which means we should hopefully see it for the Linux 3.4 kernel, but it arrived too late for the 3.3 window.

- While it's been a work-in-progress since last year, the adaptive tickless kernel support also isn't ready.

- The ARM Mali open-source kernel GPU driver is not ready for mainline integration. As I exclusively shared this morning, there's an open-source Mali graphics driver project that's created by reverse-engineering the official ARM Mali driver. This work is being sponsored by Codethink. As it wasn't too clear in my original article, ARM's current kernel Mali driver is open-source (under the GNU GPLv2), but it's the user-space side that's all closed-up -- a pretty common situation among all embedded/ARM SoCs. The kernel component has been open-source since last year, but since it relies upon a closed-source user-space, it's not suitable for mainline integration since the exposed kernel interfaces are just tapped by the blob. When there is this Codethink-sponsored open-source user-space Mali driver (hopefully done over Gallium3D), Luc Verhaegen hopes the use this same kernel module and its interfaces. At this point the ARM Mali kernel driver might be suitable to make it into the kernel since now there's an open-source "user" of the kernel driver. However, this likely won't be an item to really talk about for mainlining until at least late in 2012, unless ARM Holdings decides to also get behind this project with official support.

Hopefully some of these items will be scratched off the list by the Linux 3.4 kernel in a few months. It will be Linux 3.4 (or potentially Linux 3.5) is that we will see as the default kernel in Ubuntu 12.10, etc.