Back to the kernel [LWN.net]

Back to the kernel

Posted Apr 27, 2009 20:00 UTC (Mon) by mikov (subscriber, #33179)
In reply to: Back to the kernel by jsbarnes
Parent article: Packard on the state of Linux graphics

Well, those are good points. Undoubtedly, there is a certain elegance to doing things in the kernel, and it is very convenient. Even though kernel code is _risky_ it is also easy - you can do whatever you want in a straight-forward manner, maintain shared state and synchronization between processes for free, etc.

I am mostly concerned about the first part - the "riskiness". Adding more code to the kernel invariably will mean more bugs. Graphics code is very complex (at least the one I have worked with).

Fundamentally, putting stuff in the kernel offers only two true benefits: ability to maintain cheap shared state, and the ability to force changes to distributions in a centralized manner. (The latter is sad but true). Any other benefits are incidental.

So, if it is not terribly complex or inefficient, it makes sense to move code out of the kernel, when possible.

Of course it is absolutely impossible with some kinds of code - network and disk drivers, file systems, etc. However there are also other kinds, like USB, where user mode drivers are possible and even desirable. Graphics is somewhere between.

(Log in to post comments)

Back to the kernel

Posted Apr 27, 2009 20:13 UTC (Mon) by jsbarnes (guest, #4096) [Link]

Yes it is a complex subsystem, but wherever the code is it will be
complex, and could hang your machine. So keeping it out of the kernel on
stability grounds doesn't hold much water. (How many times has X frozen a
machine even though it lives totally in userspace?)

Also you may have misunderstood my "centralized" item: putting output
configuration into the kernel is not about pushing things to distros in a
unified way. It's about putting the code in one place that allows all
applications to benefit. In an X-mode setting world, any app that wants
full control of outputs has to be an X app. If the code is in the kernel,
any app or library can make use of it, and some already have. Projects
like Wayland and standalone EGL libraries are made possible with kernel
based memory management and mode setting. I mean, who wants to rewrite
mode setting for every chip and every type of application out there?

You're right about graphics being an oddball though: certain bits of it
belong in the kernel and certain bits in userspace. I think the line
should be drawn between memory management + mode setting and command
generation. The former needs to be in the kernel so that apps don't stomp
on global GPU state, while the latter is very complex and generally
involves mapping APIs like GL and Cairo to a specific set of GPU
instructions, so is well suited to userspace libraries.

More generally, there's a dogma out there that says "if it can be done
outside the kernel, it *should* be done outside the kernel". But such a
rule is far too inflexible. In many cases doing something in the kernel
provides such broad benefits that though a given subsystem could be
implemented differently, doing it in the kernel really is best (for
example network drivers or system checkpointing). I think kernel mode
setting and memory management clearly fall into that category as well,
since although the systems are complex they provide very widespread
benefits, and keep much of the hard stuff in one place where it can be
fixed once and used by many.

Back to the kernel

Posted Apr 27, 2009 21:59 UTC (Mon) by drag (subscriber, #31333) [Link]

Well... Think about this:

The Xorg DDX driver stuff... that had direct access to memory regions and would twiddle bits on the PCI bus, configure the hardware and things like that. Like you had it, at least partially, configuring the AGP ports and whatnot.

All of this was happenning, more or less, outside of the control of the Linux kernel and it was up to the Linux kernel, when dealing with your console or OpenGL graphics, to do what it can to avoid stepping on your Xserver's toes. If the Linux kernel or Xserver goofed up and had some sort of conflict then it would quite possibly hard lock your machine due to crashing the PC hardware.

It's rare, but a few times I've been using Linux and hte screen has gone all rainbow bright, and the lights started blinking, and the speakers started blaring static. This is not a pleasent experience.

The Xserver.. that's also a lot of code to have running around running as setuid root under your user's control. And besides the security implications involved with that... Depending on the acceleration method used by applications like Firefox you had a more-or-less direct code path from HTML/Javascript code being rendered --> Xserver --> you hardware.

Also X11 is a networking protocol. So when your running your system in the traditional X terminal mode your allowing a program that has direct access to your hardware to have network access.

So ya the Xserver and Xorg's drivers are technically 'userspace' and that is nice, but it's not really something that is hugely better then just shoving _everything_ into the kernel.

By moving the modesetting into the kernel (which is essentially low-level hardware configuration anyways...) and memory management (which Linux is good at and you can leverage the existing code for application virtual memory management) you can eliminate X's requirement to run as root, eliminate direct from your Xserver to your hardware, reduce the complexity and code redundancy in the Xorg drivers, and still have the the OpenGL stack and EXA-related stuff (except for video memory management) all happenning in userspace through a unified kernel interface.