Whether or not the graphics subsystem is part of the operating system's kernel or not is highly controversial, and popular opinion seems to change over time. For example, a certain other major OS has had graphics in, and then out of, the kernel several times now.
Whether or not the graphics subsystem is part of the operating system’s kernel or not is highly controversial, and popular opinion seems to change over time. For example, a certain other major OS has had graphics in, and then out of, the kernel several times now.
For those who have been tracking the Linux kernel for a long time will know about the General Graphics Interface (GGI) controversy way back, for example. Part of the controversy is that some of the things a graphics subsystem needs to do are really complex in nature, and thus not so suitable for running in kernel space.
Today in Linux, the graphics happen mostly in userspace, with a kernel modules (agpgart and DRM) to do some security checks. This is about to change, with Jesse Barnes from Intel and Dave Airlie from Red Hat putting a “graphics card driver” into the kernel.
Understanding the Controversy
To understand the controversy, lets take a trip back to Computer Science 201 and look at the fundamental tasks of an operating system kernel:
Resource management, including sharing and arbitration.
Abstracting hardware differences from the rest of the system (this implies having device drivers).
Enforcing the security policy.
The first element, resource management, is frankly a big mess right now for graphics in Linux. Both X and the kernel talk to the hardware, with no coordination or exclusion between them. Both X and the kernel have a lot of detailed knowledge about PCI (both AGP and PCI express are part of the PCI family of technology).
The result is that every time PCI gets some new functionality, both X and the kernel have to be updated at the same time. This should have happened in the past with technologies such as PCI hotplug, PCI domains, PCI MMIO configuration space access; the sad thing is that this in practice hardly ever happened, if at all. The end result was that distribution vendors and hardware manufacturers have been putting Band Aids on the system to keep it going– sort of.
Another area that is problematic is that of the so-called quirks: Sometimes buggy hardware is released and software needs to work around this, this workaround is called a quirk. Some of these quirks are of the type” the hardware claims to have 16MB of memory, but really has 32MB and will also use 32MB of address space”, others are even worse. In the current software stack, X will try to work around this without telling the kernel it changed the system resources. While this is just one example, and it’s not a very typical one thankfully, the total of these makes for a very messy and fragile system.
The kernel framebuffer’s driver is another weak spot. It drives the same hardware as X does, and while the framebuffer driver uses the kernel resource management infrastructure, that doesn’t help much in the arbitrage of the hardware resources since X doesn’t use these. Again the result is a fragile situation that sometimes works and sometimes doesn’t.
For me the conclusion is clear: there’s a legitimate case for putting the resource management side of the graphics driver into a central place in the kernel and resolve all these conflicts once and for all. So, now that we all agree there’s a sensible reason to at least put some part of the graphics driver into the kernel, it’s a valid question to ask how much more makes sense.
How Much is Enough?
Barnes and Airlie are drawing the line at what is called mode setting, the part of the graphics driver that tells the hardware to go to a certain resolution and refresh rate. It’s important to realize that this is different from mode selection, which is the part of the driver that decides which hardware settings are appropriate for the machine’s capabilities and the user’s selection. Mode selection can be a highly complex operation involving many factors while mode setting is a much simpler operation: it comes down to putting a series of numbers (which are calculated in the mode selection code) into specific hardware registers. In the past, the mode selection and mode setting code was seen as one big whole, and a lot of the controversy around the graphics-in-kernel issue centered around the” all or nothing” situation.
I consider the arguments for putting the mode setting in the kernel driver and have mode selection remain in userspace convincing. After resuming from suspend-to-ram, the BIOS has left the video mode in an undefined state– some BIOSes actually restore text mode, others just don’t set anything at all and leave the screen back. The only way to get the screen to work again is for” something” to reprogram the video card to have the same mode it had just before going to suspend. The mode-setting code in the kernel driver is clearly the right place to do this: doing critical suspend/resume actions in userspace is a tricky proposition which has many nasty issues.
A second argument is that the kernel can now, in the event of a kernel oops while in graphics mode, switch back to text mode and display the oops to the user. Without the mode-setting in the kernel, the user just sees his screen freeze, his keyboard blink, and can’t get any debug information off his system at all to help kernel developers find the problem.
So, in the new kernel graphics driver, the driver knows one mode at startup (the mode the hardware already is in, usually text mode) and can be informed of the hardware settings for other modes by X, or another userspace program. Switching modes then just becomes a matter of telling the driver which of the previously communicated settings should become active now. This is a setting which is easy to save during suspend, and recreate during resume for some of the graphics cards.
A positive side effect of moving the resource management and mode setting into the kernel is that it should now, in theory, be possible to run the X server as an unprivileged user rather than as the root user (since the direct hardware accesses for which X needed root privileges are now done in the kernel). It’s not quite clear yet when, or if, X will make this step, but the security conscious among us will be waiting in anticipation for this change.