Messages in this thread |  | | Date | Sun, 2 Jun 1996 14:30:02 +0300 (EET DST) | From | Linus Torvalds <> | Subject | Re: 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
|  |