Kernel internals
Ever wanted to know how modules and drivers are able to light up your display? Then look no further…
We’ve looked at how the kernel works, and how people work on the kernel. So how about we finish with some fireside kernel lore. It’s always worth remembering that every new project has its detractors (we don’t care if you thought the old website was better) and Linux was no different. The Torvalds-Tanenbaum debates, referred to as a flame war at the time (but both parties stated there was never any personal animosity, despite the colourful language), started when Prof. Andy Tanenbaum posted on the Usenet group comp.os.minix in 1992 with the somewhat provocative title “Linux is obsolete”. Obviously that title didn’t age well, but his argument was essentially that (even back then) monolithic kernels were on their way out and that microkernels were the future. As you’ll see if you’ve ever compiled a custom kernel, there’s an awful lot of stuff in there. The microkernel approach would have everything that didn’t need to be there – all those filesystems and algebraic operations and what have you – shunted off into userspace. See https://bit.ly/lxf280-linux-obsolete for the original debate in all its (really quite scorching) glory and see http://bit. ly/1cwIB5C for the battle of the Mr Ts (Round Two).
It’s an oversimplification to say Linux is truly monolithic. Modular is a much better word. Indeed, if it were properly monolithic every single driver would have to be compiled into the image and then it would probably be so bloated as to not fit in memory. That’s why drivers on conventional distros compile drivers as external modules, which are loaded at boot time. You can see which modules are in use on your system (and which modules they depend on) with lsmod . If you use the proprietary Nvidia driver (or indeed any out-of tree module or unsigned) then you’ll see an appropriately sinister warning that this ‘taints’ the kernel. Since the kernel team can’t be expected to fix bugs that might be caused by code outside their control, any bug reports from tainted kernels are summarily dismissed.
Put away your rose-tinted glasses
Sometimes life is hard for Nvidia users, but the situation is much better than it used to be. Modules need to be compiled against the same kernel version that they’re to be used with. So in ye olden days it was necessary to recompile the module before you booted a new kernel. Often the module would no longer compile against this new kernel version. And even more often you would forget to do the compiling in the first place. All culminating in the system booting to a black screen.
Thanks to DKMS (the Dynamic Kernel Module System) this problem has been obviated and new modules are updated automagically. In addition, Nvidia (and AMD’s proprietary GPUPRO stack) work much more closely with distributions to avoid any mismatching kernel situations. That open source
AMDGPU stack may be a boon for gaming on Linux, but it’s also by far the largest driver in the kernel, weighing in at 3.3 million lines (10 per cent of the 5.14-rc1 kernel).
This isn’t to say it’s bloated, sloppy programming, but rather that making graphics drivers is hard. A lot of the bulk comes from automatically generated register header files that come from AMD’s own internal specs, so this shouldn’t be seen as a burden to reviewers. New header files need to be generated for each new GPU (and they’re large), but these are stripped from the kernel at build time, so they equally shouldn’t be seen as kernel bloat. There are also a few hundred thousand blank (and comment) lines too, so the amount of ‘actual code’ as estimated by Phoronix stands at around 420,000 lines. This puts it roughly about the size of the Nouveau and Intel 915 drivers together.
Besides the drivers themselves, a lot of kernel infrastructure is needed to talk to high-grade graphics hardware. In fact, there’s a whole framework in X called DRI (Direct Rendering Infrastructure) that enables the drivers to talk directly to said hardware. In the old days of X, it had to do all the rendering since it had exclusive access to the hardware. That doesn’t play nice with today’s expectations (where applications expect to just throw OpenGL at your card and have spinning platonic solids appear in a jiffy) and the DRI in userspace is supported by the DRM in the kernel. It stands for Direct Rendering Manager, by the way, and has nothing to do with the other, digital freedom-pillaging DRM. DRM gives multiple processes access graphics hardware, whether its for gaming, video compression or crypto mining.
A question of space
Calls to the DRM API are marshalled by libdrm in userspace (and gamers in search of more FPS will often install a newer version of this library). But let’s get back to kernel space. One of the crowning achievements of the kernel’s yesteryears was promoting video mode setting from user space. Mode setting is the act of setting your display’s resolution and refresh rate (back in the day if you did it wrong then the magic smoke might have escaped from your monitor). Allowing user space programs to do this was at best clunky. It resulted in noticeable flickers and occasional distortions, and if for some reason two programs tried to mode-set at once it would be game over. Traditionally, mode setting code lived in X’s DDX (Device Dependent X) drivers, but this was suboptimal. For one thing, there was already mode-setting code in the kernel (for example, to set up the classic 80x25 text mode or framebuffer) plus there was this new emerging display protocol called Wayland.
By moving all this code to the kernel (so-called Kernel Mode-Setting, KMS), it meant it could be used by any application and that there was no duplication of mode-setting code. It also meant users weren’t at the mercy of janky programming that failed to wake their displays up after suspending and resuming the system. Further work on Atomic operations (see our Wayland of a Time interview with Dan Stone in LXF243) not only reduced the flicker between mode changes, but also reduced to zero the chance of a failed resolution change leaving the display in an inconsistent state.
And speaking of inconsistent states, this magazine risks being left in one if we don’t get this article off to our very patient printers. Do tell us all of your swashbuckling kernel adventures.