lkml.org 
[lkml]   [1998]   [Apr]   [4]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectKernel 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

\
 
 \ /
  Last update: 2005-03-22 13:42    [from the cache]
©2003-2011 Jasper Spaans