Messages in this thread | | | Date | Wed, 12 Aug 1998 22:02:31 +0200 | From | Olivier Galibert <> | Subject | Re: kill -9 <pid of X> |
| |
On Wed, Aug 12, 1998 at 08:46:02AM -0700, Linus Torvalds wrote: > Before anybody starts trying to convince me that there is kernel help > needed, they'd better have their facts straight.
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
| |