The case for the /usr merge [LWN.net]

The case for the /usr merge

Posted Jan 27, 2012 23:18 UTC (Fri) by gb (subscriber, #58328)
In reply to: The case for the /usr merge by misc
Parent article: The case for the /usr merge

> Video driver in kernel space is again rather unavoidable. If you want the kernel to manage the graphical card ( and if you want to have a text console, it has to be done by the kernel ), then you need to have part of the driver in kernel. That's what kms is about. But maybe you would prefer to have no console, or weird lock and problem because both X and the kernel use the same memory without talking to each others.

Right again, but i can recall that early Linux feature: hey, our video processing is in userspace, so you have much less chances of lockup guys! I slowly fades out. I want to add more about kernel in general, former Torvalds told 'move as much as possible out to userspace!' now it seem for me that everything moves in opposite direction and kernel is bigger and bigger. Yes, it's unavoidable again. But pity that some ideals lost.

to post comments

The case for the /usr merge

Posted Jan 27, 2012 23:21 UTC (Fri) by dlang (guest, #313) [Link] (1 responses)

the thing is that with video, more was moved out than was possible while still keeping the system reliable.

note that most of the driver is still in userspace, it's only a tiny portion that's been moved in to the kernel, just enough to be able to track (and set) the video mode.

to butcher a quote
things should be as simple as possible, but no simpler

this is just a small correction

The case for the /usr merge

Posted Jan 28, 2012 14:58 UTC (Sat) by nix (subscriber, #2304) [Link]

Memory management is also in the kernel (again, because it has to be, you can't share that sort of thing between multiple instances of Mesa, and you have multiple instances of Mesa all the time because the apps often have their own instances rather than going through the X server, for performance reasons). The command stream checker also obviously has to be in the kernel, to protect against a malicious userspace.

The case for the /usr merge

Posted Jan 28, 2012 3:43 UTC (Sat) by HelloWorld (guest, #56129) [Link]

> I want to add more about kernel in general, former Torvalds told 'move as much as possible out to userspace!'
Torvalds never said anything remotely like that.

The case for the /usr merge

Posted Jan 28, 2012 13:56 UTC (Sat) by farnz (subscriber, #17727) [Link]

And with KMS, the architecture is still that most of the video work is done in userspace. The kernel manages memory (both graphics card memory, if any, and shared system memory), dispatches command streams from userspace to the GPU in a safe fashion (stopping apps disrupting each other or accessing each other's memory space), handles interrupts, does modesetting, and resets the GPU when userspace apps crash it.

Everything else (all the complex command stream creation) is done in userspace still.

The case for the /usr merge

Posted Jan 29, 2012 21:45 UTC (Sun) by sbergman27 (guest, #10767) [Link]

"I want to add more about kernel in general, former Torvalds told 'move as much as possible out to userspace!'"

Linus has never taken that position. All other things being equal, he favors that things stay in user space. But if there is good argument for moving it into the kernel, he's always been OK with that. In fact, he has been very explicit on the point that the goal should not be to keep the kernel small, but to make the right decisions as to what goes in and what does not.

The GGI guys wanted to move the whole graphics driver nightmare into the kernel. Linus put his foot down on that idea. But DRM, memory management, and kernel mode-setting were the peices of Linux graphics which were always fundamentally broken under the old "all graphics in userspace" model. Do you know that switching from X to a text console and back has never been guaranteed not to hard lock your machine? Surely, if you've been around long enough, you've encountered such console crashes. And when that happened, it was likely not a bug, per se. It was the result of a fatally flawed design. Only with the inclusion of KMS is your distro's graphics system not fatally flawed at a fundamental level.

Regarding your concerns about the size of the kernel, what does it matter? The vast majority of kernel code expansion is in additional drivers. And those are all modules. Modules whose code-bases are orthogonal to each other.

In comparison, DRM, KMS, and GEM are not particularly large. I'd never want to go back to the bad old days of our former "Green Acres" graphics architecture.