To read all comments associated with this story, please click here.
Member since:2006-02-06
It can look that way but (at least the way I understood it, but I don't know much about the subject) it seems like what they are migrating from user space to kernel is some basic direct hardware access that X was doing before, basic functionality that really belonged in the kernel in the first place.
But even if that is wrong, I have to say that, given the problems this idea might solve, I'm all for it, being it modern or not 
Member since:2005-08-26
It belongs in the kernel, as part of the gfx driver.
Having X11 handle modes (and host drivers) is retarded. Always has been, always will be. Hardware drivers should be tied to the kernel. Having them driven by a user-space app is a kludge at best.
At any rate, this is how BeOS & Haiku do it, and I'm sure countless other OS's out there that don't have their craniums firmly planed up their posteriors.
Member since:2005-07-24
Don't be such a slave to fashion. ;-)
Counting lines of kernel code vs userspace code is pointless. If it makes sense for functionality to be in the kernel then it should be in the kernel.
One of the major issues here is central control. There needs to be one entity in charge of setting the vid mode. Otherwise you end up with conflicts that can potentially lock up the machine, or at least the console. And you end up with ugly screen flashes and annoying delays during bootup, shutdown, and vt switching. Plus redundant code in kernel and user space which may have different expectations. The alternative would be to move sysvinit (or upstart) and the Linux text consoles all into X, which would be quite absurd.
The piece of functionality that is going into the kernel is actually quite small, and some or all of it is already implemented in the kernel to allow that cute little Tux logo to display on bootup. Mainly, I believe that an API for existing functionality is just being exported to userspace for use by X or the windowing system of your choice. And the result should be enhanced stability. And enhanced security, too, since the kerel API should cover all of the functionality which has thus far required the X server to run as root, allowing X to run as an unprivileged user.
Edited 2008-04-22 19:31 UTC
Member since:2007-08-12
You could implement an elegant solution in userspace with a display server in a microkernel OS. Or you can do it in userspace with a monolithic kernel as well, but with no integration with other parts of the OS, and it's yet another reason why the program needs to be suid root...
In my opinion, given this context, moving that stuff into the kernel makes plenty of sense.
Member since:
2006-01-22
I don't know much about this things but I thought bringing things out of kernel space into user space services is "modern"? So is this really a modern way to handle things? I don't know.