Messages in this thread | | | Date | Sat, 28 Mar 1998 13:13:52 +0100 | From | Vojtech Pavlik <> | Subject | Kernel videocard support YES or NO? |
| |
On Sat, Mar 28, 1998 at 04:23:09AM -0500, linker@nightshade.ml.org wrote:
> If the kernel does not have concise control over a piece of hardware then > a user app must control it. > If a piece of usercontroled hardware needs it's state set then the userapp > must set it and un set it as nessassary > If a userapp crashes or gets killed (or conflicts with another user app) > it cannot unset any states. > If you know nothing about a modern videocard, you cannot send it a magic > string to reset to a sane state > The console is a critical subsystem, especially on user boxes. > If the console is crashed then the computer is effectivly crashed. > Linux should not crash. > > Therefor the Linux kernel needs to understand the hardware, so that it can > control the state.
------------
Yes, I can only second this. I'll list a couple more reasons why graphic card support SHOULD be in the kernel:
* In userspace you can't use interrupts, which some newer cards generate. (eg. Riva 128)
* In userspace you can't do DMA well, and DMA is very useful with never videocards and there are some whose performance would be poor without it. (eg. Pyramid 3D)
* In userspace it is not a good idea to do a cli(). It's a big stability risk. However, this is needed for many graphic cards to communicate with. (You should cli() even for a standard VGA, because of at least one register that's flipflopping between index and data state.)
* In userspace you can't do good console switching, because many videocards (eg. SPEA Mirage P-64) have write-only registers, and with that it's impossible to properly save and restore video state when you don't have centralized support for it.
* There are cards which don't have (or have very poor, eg. ARK, Trident) textmode support, and it's sad to have to see 80x25 textmode (or the ugly 8-point `standard' 132x43 mode) on a 21" monitor. Allowing a framebuffer console on the PCs would be nice.
* In userspace you need to have root privileges to control the video subsystem, which inherits security and stability risks. (Eg. A buffer overflow in the application can give you root access)
* Acceleration support should be in the kernel, too, because most of the 3D accelerated cards use DMA, which can't be well used outside kernel, and, if done, must be restricted to root privileged user only, because it gives you a complete control of the system. Thus you'd need setuid graphic programs.
* In XFree, there is a huge generic X11 code, and much smaller driver part. However, all of the code has access to the whole system, since it runs with root privs. Thus a crash anywhere in the 2 megs of code can crash your system. If the driver and generic parts were separated, crash in the generic X code would only result in X crashing (And restoring to text mode) and not system crashing.
* Were the graphic card support in the kernel, the applications could work with abstract enough layer and not have to deal with every card possible, eg. it won't be needed to have many different X servers. (The whole abstraction layer wouldn't need to reside in the kernel, but in some library. In the kernel there could only be functions to safely use all the feature of the one specific card the driver is written for.)
* Were the graphic card support in the kernel, it'd be enough to add a new driver to the kernel, and not to have to write several drivers for XFree, SVGAlib, SVGATextMode, DOSemu .... Thus work could be saved.
* Were the graphic card support in the kernel, and the same .graphic. mode usetd both for X and on console, the switching would be lightning-fast, as the monitor won't have to resynchronize.
* There is already fbcon for other (non-PC) architectures.
----------
That's my list of reasons why there should be graphic card support in the kernel. Maybe I'm missing some, feel free to comment and add. Follows a list of reasons why NOT TO ADD it:
* Possible kernel bloat.
* Possible slowdown versus monolithic XFree.
* Having to write all the drivers that already exist in XFree, and the porting of the drivers won't be really straightforward, because the (non-XAA) XFree servers use different approaches to acceleration.
* Breaking the (current) line between the kernel and X, which is mainly organizational issue, because the drivers are developed by XFree people, and not by the kernel people at the moment.
------------
And, last, I'll comment on the VESA thing being discussed:
* VESA 1.0-1.2 is not worth being included, because of the need to use vm86() and virtually including dosemu into the driver. It could be done, but it's not a good idea.
* VESA 2.0 is becoming quite common in videocards and it'd be nice if the (kernel?) driver could use it as a last resort when it can't handle the hardware directly. It's 32-bit, so it can be called directly.
------------
That's all. Hope it helps you all there consider what should be done. I don't say it has to be KGI/GGI, but, KGI/GGI is very close to what I think would be good.
Vojtech Pavlik
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu
| |