>
> Hello,
>
> This, I think, is about as bare-bones as support for graphics mode
> switching in kernel can get. Heck, it'll even work for other kinds
> of hardware as well!
>
> One syscall only is needed. To switch into a new mode, the caller
> provides code to do some and code to switch back. Both code
> sequences are copied to kernel memory (so they had better be
> position independent!) where the setup code is run right away
> while the restore code is saved. Any (root) process can switch
> back by calling the restore function.
>
> The obvious extension is to parameterise on hardware.
>
> This code does not prevent anyone from shooting himself in the foot.
> (Just send bogus setup/restore code, for example.) But an X server
> crash should no longer be a problem.
>
> [Thinking aloud:] Alternatively, one could have a sys_hardware which
> does nothing until a module tells it what to do. That way, the kernel
> would not get anouther place where arbitrary code gets injected.
>
[snip]
Why have the kernel copy the code, why not have the code in a module?
Could the user space code not ensure the module is loaded, and then do a
syscall to register the save/restore resource functions within the module
with the kernel?
P.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu