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.
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
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.
I thought bringing things out of kernel space into user space services is “modern”?
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.
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.
Hey guys, something just struck me: How would one go if one wanted to change video modes on the fly with this technology ? is it easily accomplished or would it require some weird stuff, or booting or anything ?
Sorry for the probably stupid question, I truly believe it would be painless, but I think I should ask just to be sure.
I imagine you can change settings on the fly, that would in fact be part of the point of sticking the code in the kernel…
Re the comic: Linux has been far more advanced than most other OSs for a while, admittedly it loses out slightly to OpenSolaris, and a Cocoa like GUI system would be nice, but Linux is pretty darn good, and far more modern than Windows. Program Manager anyone (still in sys folder afaik)?
and far more modern than Windows. Program Manager anyone (still in sys folder afaik)?
Nope, they got rid of it in Vista. Now how am I going to manage my programs!?
Linux is more advanced than Windows on many layers, but it still falls flat on the GUI end of things. Seriously, try manipulating installed hardware drivers in Linux, and you’ll see what I mean.
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.
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
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.
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
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.
Hey guys, something just struck me: How would one go if one wanted to change video modes on the fly with this technology ? is it easily accomplished or would it require some weird stuff, or booting or anything ?
Sorry for the probably stupid question, I truly believe it would be painless, but I think I should ask just to be sure.
I imagine you can change settings on the fly, that would in fact be part of the point of sticking the code in the kernel…
Re the comic: Linux has been far more advanced than most other OSs for a while, admittedly it loses out slightly to OpenSolaris, and a Cocoa like GUI system would be nice, but Linux is pretty darn good, and far more modern than Windows. Program Manager anyone (still in sys folder afaik)?
Nope, they got rid of it in Vista. Now how am I going to manage my programs!?
Linux is more advanced than Windows on many layers, but it still falls flat on the GUI end of things. Seriously, try manipulating installed hardware drivers in Linux, and you’ll see what I mean.