The kernel is actually not needed for anything but managing the VM and
giving special priviledges to given processes. Microkernel
architectures have shown that.
Now a more reasonable question is "what support the kernel could
reasonably give when it comes to graphics?".
Actually, when you want to do graphics on linux you have two
possibilities:
- if you want high bandwitch and/or fullscreen, svgalib
- if you want integration within the user desktop, X
Both of these have problems. Please consider in the following that
the "application" may not be a game but also something like a serious
movie editor or realtime special effects generator.
svgalib:
- requires the application to be suid-root and gives it some
priviledged accesses to the hardware. Writing recure applications
is hard and dropping priviledges at the start is not enough. You
also have to revoke the priviledges before execs et al. Some
security models consider the process tainted and automagically
disables some features like NLS.
- is not very portable. It will be very difficult to use it on
non-intel hardware, in particular the ones without an accessible
framebuffer. Such evolution of graphic cards seems to be the way of
the future from intel hardware too.
- has a limited acceleration support, even if it seems to handle gl
nowadays.
- has less drivers than XFree86.
X (and in particular XFree86):
- requires a huge suid-root server (with the same revokation problem)
which performs two essentially different tasks:
* drives a video card the fastest possible (this part will jump into
XAA)
* handles the X protocol and semantics(windows, events, colors,
pixmaps, etc...)
- is not very good at high bandwitch movie displaying, especially if
you need stretching support. MIT Shm is not good enough (it can't
stretch, it often can't use the video card internal format
conversion routines because there is no "supported format"
negociation) and there is no X extension for that right now.
XFree86 cruising away from TOG may help in this area. AFAIK, for
the same situation SGI uses special extensions to OpenGL and
achieves 1280x1024x24x60fps zoomed animations.
- is somewhat huge in what it requires from a conformant application
(color management, i18n input methods, ICCCM et al.). This is good
in general for the user, but an overkill at times.
Reasoning further we see that svgalib is a thin layer on some drivers,
and X a big layer on a sea of drivers equivalent to the svgalib ones.
Also, one may want to go and try another approach at graphics which
isn't directly X or svgalib compatible, for instance Berlin, or for
implementing a fast DPS for gnustep on top of the graphic card instead
of going through X and having to implement something slightly
different on X semantics.
Because of that, it would be nice to have a common graphic driver
architecture for everybody who wants to provide new ways at doing
graphics. X and svgalib are good but have their failings too, and
trying other approaches can give interesting results. XAA may be a
good candidate for such an architecture. Of course this is not
*required*. One can think that X is enough, or that graphics are for
bimbos. But the MS Direct* saga, BeOS, Berlin and the current graphic
cards wars show that lots of ideas are floating around about how
graphics should be done, and locking ourselves on X, which requiring
everybody wanting to experiment to write its own drivers would result
in, would be very sad.
Now the question is, where to actually put it. What is required by a
graphic driver?
- direct accesses to i/o ports.
- direct accesses to device memory, including sensitive parts usable
for crashing the machine or capturing priviledges.
- interrupts.
- fast interrupt-to-action turnover.
Usually, the "interrupt" point is a big enough a hint that this
belongs to the kernel. But in order to be objective, let's see the
alternatives:
1- shared library to be used by root applications
Pros:
- Nothing special needed in the kernel. I agree this is an important
point.
Cons:
- Requires a client/server architecture if you want to avoid suid-root
applications. Such architectures are neat but have a cost. *Each*
of these interfaces will have to be optimized independently for each
system.
- Applications or servers will have to share some data about the card
state in order to handle card configuration and VT changing nicely
if you want to be able to say start X and a svgalib application
simultaneously.
- No security when experimenting. A wild pointer can destroy the
local memory enough to crash the card and lock the PCI bus, or if
Murphy is around have it send high-frequency signals the monitor
will yell about.
2- Kernel level drivers
Pros:
- Security (modulo bugs of course, but this is always a integral part
of the equation) ensured by the already existing client/server
kernel interfaces (syscalls, mmapping, special files or ioctls).
This will also provide an interesting experience on how to do
high-speed user/kernel communications which will be necessary for
high bandwitch networks.
- The card state is internal to the driver and no sysv shmem or
whatever is needed.
- In the long term, possibility to do accurate video/audio
synchronisations.
Cons:
- Yet another device type in the kernel, with all the bugs following,
and yet another bunch of modules will have to be maintained. But
then, this is exactly the same than for sound, disk devices, network
cards, ...
- The interface can't be pure XAA, so the XFree86 folks may not like
that. A kernel interface - XAA conversion layer, hopefully very
thin, will probably be needed.
Here it is. I hope to have exposed clear arguments about why a
graphics support evolution would be useful, and why a kernel-level
architecture seems interesting. Please feel free to complete the
"Pros/Cons" lists and/or provide datapoints or arguments on the
relevance of an independant graphic drivers architecture.
Also, please note that I didn't say a thing about KGI/GGI. Whether
something is needed and how it should be implemented are independant
decisions.
OG.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.altern.org/andrebalsa/doc/lkml-faq.html