lkml.org 
[lkml]   [1996]   [Jun]   [2]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: SVGA kernel chipset drivers.


On Sat, 1 Jun 1996, Jon M. Taylor wrote:
> >
> > >The ONLY solution is X, and anything else is just noise. They should be
> > >supported, but not at the cost of extra complexity in the kernel.
> >
> > Truly. I have worked on projects where 70% of the coding and
> > debugging and testing effort required to support a board under certain
> > OSs was wasted on the goddamn text-graphics-hotkey-dos-compatibilty-lcd-
> > panel-virtual-device-etc bullshit! Go into graphics and stay there or
> > don't go in at all.
>
> Jesus, this isn't THAT big of a hassle! You are exaggerating.

Umm.. Look at the state of DOS and Windows 5 years ago..

Not having a windowing system is simply unacceptable. Doing graphics in a
program "by hand" is like using a PC/XT - it's technology that is going
away. People may still use it, but I'm not going to put code into the
kernel that I feel has no future..

> Look there are things wrong now, and kernel video would be a
> AWFULLY convenient way to deal with a lot of them in one fell swoop.
> Sure, it isn't going to be a walk in the park, but it'll be worth it and
> it IS doable.

Sure. It's convenient to just say "do it in the kernel".

In short, it's convenient to try to shuffle onto somebody else. That
somebody else happens to be ME, which is why I don't think it's in the
least convenient, I just think it's a horribly braindead idea.

Somebody said that "we have to have the complexity anyway", and he's damned
right. However, if he thinks moving the complexity into the kernel is the
answer, he's wrong. With X, the complexity is exactly where it should be: in
user space, in _one_ trusted binary, and all the graphical programs don't
need to be very clever or trusted.

> > All the
> > high-end cards that I have worked on have frame buffers. Why?

Sure, most of them do have frame buffers, that's not the issue. However,
some of them don't, sometimes because they have special hardware like
Z-buffering that they don't want to expose to the programmer or stuff
like that.

> At the very least, it is common enough that it isn't worth
> worrying about overmuch.

Umm.. It may not be worth worrying about on a user level, but it's damn
well worth worrying about in the kernel. I'm not going to write a kernel
that doesn't work with a certain set of cards or that conceptually
cripples them.

Don't people understand about the kernel?

The kernel is NOT there to make it easy for people. The kernel is
supposed to be a MINIMAL resource management thing, and when it comes to
graphics it really doesn't belong in the kernel.

Other UNIX'es _do_ support framebuffers, but they are often limited to a
very specific set of hardware platforms, both when it comes to the actual
bus/CPU and when it comes to the graphics device.

> > Anybody using a card that is I/O mapped should not complain about the
> > performance -- they are using intrinsically suboptimal hardware and
> > there is no reason to make hacks for it when they could be using good
> > hardware and leave programmers to work on projects which advance the
> > state of the art instead of holding it back.
>
> On the other hand, one of the strong points of Linux is that is
> supports even old, slow, brain-damaged hardware and pushes it as far as
> it can go.

Sure. But that support is not necessarily in the kernel. In fact, the
fact that the kernel is small and streamlined means we can more easily
use Linux on the small and old machines, and people who don't need
graphics don't take the performance hit of having lots of graphics
complexity in the kernel.

In short, the solutions for the slow and brain-damaged hardware without
enough memory to run X decently etc is STILL in user-level.

> > >Trust me, we're not talking VGA here. We're talking _high_ end graphics,
> > >that don't have frame-buffers because that interferes with the normal
> > >mode of operations (painting the screen) for no real good reason (the
> > >actual drawing is then done using screen commands and/or DMA to the card
> > >to fill a area with data).
> >
> > Are you thinking of the XGA? That's the only card I can think of that
> > uses DMA.

Get your mind out of the gutter of PC hardware.. It seems some of the SGI
graphics card use DMA exclusively, for example. And I wouldn't call the SGI
graphics hardware exactly broken..

I've heard others talk about the new generation 3D-accelerated PC cards
too, so it exists even on the PC side.

> Better that than have that hardware be completely unusable, no?

This whole question is _NOT_ about being completely unusable or not. Even
without kernel support, you can create usable graphics drivers, and in fact
it's usually a hell of a lot easier to debug and program them that way. It's
often also noticeably faster, because you don't need to trap into the kernel
when you need to do something that needs support from some broken kernel
graphics driver.

If people are complaining about SVGA programs that lock up and crash and
leave the graphics screen in a strange state, they should really start
looking at the program itself. For example, people have claimed that a
SVGA program needs to be set-uid with all the security problems that
entails. This simply IS NOT TRUE!

For example, you can obviously write non-setuid programs that write
graphics: just look at X. Yes, the X server needs to be setuid, but
people generally trust X - it's been well written to gracefully handle
most problems.

The same way you can create SVGAlib type programs that can much more
gracefully handle programming errors. Just as an example of this, you
could do this all safely in user mode with something like this:

svgaserver.c (set-uid skeleton program):

int main(..)
{
int pid;
.. move to graphics mode ..
.. map the "frame buffer" by mmapping /dev/mem ..
pid = fork();
if (pid == 0) {
void * program;
/* child process - get rid of all root privileges */
setuid(getuid());
.. get rid of whatever other special privs ..
.. we picked up for graphics and we don't need ..

/* run the supplied dynamic "library" */
program = dl_open(argv[1]);
if (!program)
exit(1);
exit (dlsym(program,"run"))();
}
wait(NULL);
.. return to text-mode, unmap frame buffers ..
return 0;
}

See? This is NOT A KERNEL ISSUE!

If you do it like the above, you can just have a "svgaserver" program
that is _safely_ able to run any user-supplied binary at all, without
giving that dynamically loaded binary any super-user privileges. More
importantly, you can make the "svgaserver" program handle virtual console
switching etc - you just do a simple protocol for that (for example, the
parent gets notified when the child gets stopped, so the svgaserver could
automatically move into text-mode when that occurs, so you can _force_
this from the outside by just sending the child a SIGSTOP signal or
something.

The above is a lot more generic than any kernel approach, and gives you
everything the kernel could ever give you.. And yes, you end up with a
setuid binary, but that's the whole idea with setuid: you can create
server binaries that can do error checking and that are trusted, and with
the above kind of setup the svgaserver binary really doesn't need to be
very large at all.

Putting graphics into the kernel is WRONG, and people who keep suggesting
that just haven't thought about all the issues.

If there are people out there who think they can do graphics programming
in the kernel, they should be competent enough to do the above kind of
"svgaserver" binary too.

Linus


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