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 Sun, 2 Jun 1996, Linus Torvalds wrote:

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

To you, maybe. I *like* fullscreen VCs, and I'd like them even
more if they could be put into graphics modes as well. I almost always
use Lynx instead of booting X to run Netscrape, I always played the
SVGALib version of Doom instead of the X one, and I don't do any
development in X. This is a personal issue, though, and not really to
the point.

Suppose I loved GUIs, but I wanted to write my own instead of
using X. I'd have to either come up with all of my own video driver code
or recycle mammoth quantities of same from the XFree sources. What a
waste of time! Also, the same situation that exists now with XFree86
would still be present - I'd have to code up separate server executables
for different video chipsets because there isn't one underlying
system-level interface. This is why the X diskset from Slackware is so
damn big!

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

I take it that you are going to remove the XT hard drive support
from the kernel, then. Besides, I have a feeling that this may not be
quite as obsolete as you make it out to be. We aren't talking about
people having to write GUIs on their own for each and every program, ve
are talking about not having to lug around the huge overhead of a GUI
when it isn't necessary.

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

No one has asked you to do anything related to this except be a
bit more open-minded about the concept in general. As long as it doesn't
screw up anything ELSE in the kernel (which the GGI is specifically being
designed NOT to do), why worry? Let that be our problem.

> Somebody said that "we have to have the complexity anyway", and he's damned
> right.

That was me.

> However, if he thinks moving the complexity into the kernel is the
> answer, he's wrong.

Once again, why is it wrong to do this for video cards but not for
sound cards? Sound cards are very diverse, have an incredible number of
/dev/ entries (mixer, sequencer, patmgr, music, midi, dsp, dspw, audio,
and sndstat), and have a gigantic drivers directory with tons of different
source files for tons of different cards, and yet Hannu did a great job of
making it all work pretty nicely. Why is that so different from the
GGI? Hell, we only have *one* /dev/ entry! |->

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

But they *do* need to use X, right? Sorry, but X is not part of
Linux. I do not think that it is reasonable to be forced to use one
particular GUI in order to use graphics.

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

So we come up with something that adequately abstracts *whatever*
features the card has to offer. Maybe it requires another /dev entry at
some point or whatever. As long as the feature in question is
hardware-based, the addexe complexity will be minimal. Remember, our big
point is that the stuff in the kernel is the minimum necessary to control
access to the card while presenting as uniform an interface the userspace
programs as possible. That really doesn't have to be either very big or
very complex (relatively speaking).

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

As long as basic VGA support exists (a given, pretty much), very
very few cards won't be usable for at least that much functionality.
Support for the more advanced stuff on the card will be like everything
else in the kernel - it'll develop with time.

> Don't people understand about the kernel?
>
> The kernel is NOT there to make it easy for people.

Easy? No. *Possible at all*? Yes.

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

Minimal is rarely zero.

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

Why on earth should we be limiting ourselves just because other
Unices are limited too? Besides, at least they have *something*.

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

They won't. Obviously, the GGI would be a subsection in the
configuration menu that would allow for stripping it down to minimal
functionality if necessary, just like most other device drivers. In fact,
if all that card-specific stuff that's there now were part of a general
video card driver framework, conditional compilation could compile out 90%
of the stuff for other people's cards except yours, and that code would be
smaller than it is *now*! Everything from nothing-but-MCGA-text to
incredibly elaborate gaming cards (and all options in between) would be
possible and fully configurable at the user's discretion.

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

You must like X an awful lot |->.

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

That doesn't mean it's the right way to do things.

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

That speed comes at the expense of stability. Usermode programs
should not be hitting the hardware directly. Ever.

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

I have. It is called XFree86.

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

Semantics. X is what is ultimately poking the hardware.

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

In the meantime, our program has fallen over and is scribbling
all over /dev/mem....

> /* 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!

But it SHOULD BE! When a buggy program can screw up the system
for everyone else, the kernel is not doing its job. Even if the X server
was bug-free and NEVER had ANY problems hold its end up (which is not the
case), the fact remains that a user-level program is CAPABLE of falling
over and taking the whole system with it. Whether or not this will ever
happen in the real world, it shouldn't even be POSSIBLE.

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

The fact remains that a user-level program has to have root privs.
All this 'user-level SVGA server' concept does is take one program's flaw
and extend it to every program that runs on top of the server.

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

Gack. Now we have a user-level program handling VC switches,
too. You've just recreated the 'X server falls over and you can't switch
VCs or even reboot gracefully' problem that X has and that I have been
bitten by many times.

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

It is a kludge. No matter how 'trusted' your program, no matter
how bug-free it is, the fact remains that you are subverting one of the
primary functions of the kernel (acting as an absolute authority WRT
arbitrating access to IO devices).

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

I have DONE a lot of kernel level graphics programming over the
last six months, developing a Mach32 driver for the GGI. Trust me, the
concept works. There's a lot of work left to do, of course, but the
basic concept HAS BEEN PROVEN TO BE SOUND. I have a patched kernel
wherein I can write a plain-jane non-suid executable that can open a
graphics screen on one console, write to it, and a VC switch will work
perfectly and bring up textmode on the switched-to console. IT WORKS.

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

Yes, but we are working on the GGI instead, because It Is The
Right Way To Do Things.

Jon Taylor = <taylorj@gaia.ecs.csus.edu> | <http://gaia.ecs.csus.edu/~taylorj>
------------------------------------------------------------------------------
"Everything in excess! To enjoy the flavor of life, take big bites.
Moderation is for monks." - Lazarus Long





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