lkml.org 
[lkml]   [1998]   [Aug]   [12]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: kill -9 <pid of X>
On Wed, 12 Aug 1998, Olivier Galibert wrote:

> 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.

Thanks for taking the time to put together the list below. It is
so nice when people contribute to the discussion instead of flaming...
anyway, I'll add my comments as needed.

> The kernel is actually not needed for anything but managing the VM and
> giving special priviledges to given processes. Microkernel
> architectures have shown that.

Operating systems are supposed to multiplex the hardware as
efficiently and securely as possible.

> Now a more reasonable question is "what support the kernel could
> reasonably give when it comes to graphics?".

"Reasonable" can be looked at after "essential" is taken care of.

> 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

- If you want stability and the ability to run graphics apps without
needing any special privs, fbcon.

> 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.

- Has a sucky API.

> 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...)

* Handles VC switches

* Drives the keyboard and mouse(?) directly.

> - 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.

SGI's video cards also support OpenGL right on the hardware. That
helps a LOT.

> - 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.

That's the Berlin project's gripe - X is too restrictive. Either
you do things the X way or you use XAA and lose a lot of the X stuff you'd
have liked to keep. Feast or famine.

> 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.

Linus himself has said that X == graphics as far as he is
concerned.

> 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.

I think so too.

> 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.

- Critical section locking (no scheduling preemption or interrupts)

- Ability to handle page faults, if you want to have a pseudo-linear
framebuffer.

- Ability to consistently track the hardware state

> 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.

It's nice if it works right.

> 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.

And also optimized for the hardware<->system interface as well, if
you want maximum speed. Each generic interface you have to go through
between the hardware and the graphics-using apps chokes off some of that
optimization space.

> - 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.

This can't be gotten away from when you are developing video
drivers, no matter where the drivers are.

>
> 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.

That last is a good point. High-speed graphics requires
efficiency in other parts of the kernel to implement optimally. KGI, for
example, needed to add a new fast page remapping feature to mmap.c in
order to handle pseudo-linear framebuffers with acceptable speed.

> - The card state is internal to the driver and no sysv shmem or
> whatever is needed.

One hand firmly on the wheel at all times. Modular, compact,
efficient, stable, clean.

> - In the long term, possibility to do accurate video/audio
> synchronisations.

When the bandwidth gets high enough, actual scheduler changes will
be needed to handle this sort of thing properly. IRIX has a whole other
scheduling subsystem devoted to IO management. But that is a topic for
the future, thank God.

> 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, ...

And the drivers will be cleaner, smaller and GPLed. Their
maintenance will be open to the tens of thousands of Linux users/hackers,
not just a small cabal of XFree86 developers that also have to worry about
lots of non-driver issues.

> - 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.

Yes. The new Degas-KGI will have some sort of direct-to-driver
XAA suport in the kernel drivers themselves, which should help a lot.

> 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.

Seem my comments. You did a good job.

> 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.

Indeed. Fully accelerated kernel graphics can be done with the
fbcon system we have right now. The GGI project thinks that our code is
better for a variety of reasons, but fbcon will work just fine. People
just need to write those accelerated fbcon drivers and make userpace apps
support those per-driver accelerations. It can all work well right now.

Jon

---
'Cloning and the reprogramming of DNA is the first serious step in
becoming one with God.'
- Scientist G. Richard Seed


-
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

\
 
 \ /
  Last update: 2005-03-22 13:44    [W:0.235 / U:1.024 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site