> I can see several reasons for people wanting to "enhance" the
> kernel/graphics card "cooperation":
>
> 1. Security, setuid is a big problem just to do graphics
>
> 2. Speed, lots calls to ioperm()/iopl() can't be good for
> performance
>
> 3. Tidyness, Some might say it makes more sense for the
> kernel to do for graphics what it does for sound.
>
> 4. Quicker uptime with new graphics cards in userlevel if we
> can assume some basic interface. (JoeWhizo new graphics
> card can run, but not at it's best X on last years kernel
> even when we don't have any specs for it yet.)
5. Kernel oops while running X
6. X crashes (out of swap maybe)
> My comments on these "reasons":
>
> 1. This problem is already solved -> POSIX.6, the process
> (XF86_*, or SVGAlib) gets the single priv to use ioperm/iopl and can't do
> anyother things a setuid0 binary can.
No. If you get the POSIX priv to do port IO, then you can get full
privs by using the disk controller directly. This POSIX priv is
useful to protect against buggy programs that exec other programs,
but it does nothing to allow normal user access to video hardware.
You still have to set a special bit that a normal user can't set.
> I don't think SVGAlib as it stands is cutting it, and I really don't care
> how many XServers there are - I've got 3 different Xservers on my Sun at
> work and only one XF86 server at home, disk space bloat isn't an issue -
> you only install the one you really need and if the SVGA one is a bloat
> that causes you concern then you need a better install program that
> relinks with only the card you have in your machine (but as I understand
> life in Linux this don't really matter much anyway because of
> demandloading and friends).
One problem with usermode graphics is the kernel oops while in
graphics mode. If the problem is at all disk related, then you will
never see the oops.
Simple way to mess up a Linux machine so bad that it must be rebooted:
Run something that eats all the swap and something else (over net?)
that makes the X server grow. A fork bomb and Netscape might do the job.
(With resource limits, just make the X server grow - it runs as root.)
Linux kills the X server but is unable to restore text mode. It can
restore keyboard mode, but it doesn't do that either. If you have the
SAK patch or some way to telnet into the machine, you can fix the
keyboard. Depending on your video card:
a. It is completely hopeless and you must reboot.
b. You can use SVGATextMode to fix the problem.
c. You can start the X server, but when you quit it restores the
messed up video instead of textmode. (most common case?)
d. You have some tool you can run from DOSEMU.
Note that all of these "solutions" are hardware-dependant hacks.
There is no general way to fix the Linux console after it is messed up.