> Don't people understand about the kernel?
> The kernel is NOT there to make it easy for people. The kernel is
> supposed to be a MINIMAL resource management thing, and when it comes to
> graphics it really doesn't belong in the kernel.
> Putting graphics into the kernel is WRONG, and people who keep suggesting
> that just haven't thought about all the issues.
>
> If there are people out there who think they can do graphics programming
> in the kernel, they should be competent enough to do the above kind of
> "svgaserver" binary too.
Totally aggree about the current situation ... (but, with all respect):
besides all the stuff you understand much better than me, kernel traps are
there to provide entry to a new security domain. With all it's local
context, which >is< protected. Not so in normal user space. Static data
structures might get damaged if in the same process.
You might argue that if i need it, i can code up an "SVGA daemon" that is
in another protection domain, and switch to it if i need such wierd things
like protection ... but that is much slower currently IMHO than a kernel
trap. And it's not really supported by the scheduler to do "go fast to
that other process but come back afterwards as if you were doing a kernel
entry". Dont even know if it makes sense.
All issues like unified FS in user space, or SVGA in userspace are
crippled by this problem IMHO. Too expensive to implement it in another
process, and too unsafe to implement it in the current process. And Linus
doesnt want it in his kernel [and he is right, but where should it go then] :)
simple: a kernel trap is currently the cheapest protection domain switch
[ well, the local stack for a library call is usually enough protection,
but not always ] (and i >want< protection for files in a unified FS)
Maybe this is silly and there exist services that do exactly this, in
userspace, in a safe way, and as fast as a kernel trap. Sorry if so, but i
think many people dont see the way out [the GGI people for example].
best regards, Ingo Molnar