Re: GGI and cli/sti in X

Linus Torvalds (torvalds@transmeta.com)
29 Mar 1998 02:27:30 GMT


In article <Pine.LNX.3.96.980329001730.31040W-100000@rainbow.studorg.tuwien.ac.at>,
Andreas Kostyrka <andreas@rainbow.studorg.tuwien.ac.at> wrote:
>
>> loading. Obviously it was pretty slow, but switching to console and back
>> actually got faster as I did it more and more. At the end I killed -9 the
>> X server, no problems.
>
>You killed it on a text console, or in the Xserver. I assume that you
>killed it on a text console, where this is the normal behaviour. (The
>X server restored textmode when you switched away, and kill -9 doesn't
>give it time to do something sneaky anymore :) ).
>Try this from on xterm in the Xserver *g*

What they hell is it with these GGI advocates?

THINK for a minute, Andreas?

The "kill -9" problem is so trivial to fix that it's scary: you make a
small setuid binary that runs as root (and makes sure to drop the
original user by doing a "setuid()" as the first thing). It saves the
old graphics mode information, switches into graphics mode, does a
"fork()" and starts up X as a normal user in the forked process.

The small root-owned process then stays around, does a "wait()" on the
child (the X server) and when the X server exits it restores the screen
and everything is hunky dory.

And you _cannot_ kill the small setuid program, except as root. And it
you are root and kill a system deamon its your own damn fault. If you
kill your X server, nothing bad happens (except your X server goes
away).

Does this sound complicated? No. There was even some code that did
something like this with some graphics cards where XFree86 was unable to
correctly restore text mode due to some XFree86 implementation problem
(which was fixed).

This is what I mean by the GGI people throwing out the baby with the
bath water. Yes, X has a few silly problems, but GGI is not the
solution. Using your brains for a second is the solution, at which
point you notice that "hey, I can fix this problem easily without having
to really rewrite huge parts of the system".

The same goes for input timing that somebody brought up as a thing that
"required" EvStack and kernel changes. No such thing is required at
all: it is fairly trivial to have a very small thread that works as a
real-time process and has done a mlock() on the buffer it uses for
events. Or probably hundreds of other solutions.

And people still wonder why I'm not too impressed with GGI? No, I'm not
very impressed with people who think they have to rewrite the whole
world in order to fix a few small problems.

NOTE NOTE NOTE! I realise very much that maybe the right approach to
mode switching is to _have_ kernel support for graphics modes. In some
cases it simply is a lot simpler to just use a kernel module to do some
things. But I have no understanding at all for people who chant the
mantra of "GGI" and think that it solves everything, and more
importantly think that there is no other way to solve the problem.

In short, when you have a complaint against XFree86, like the entirely
valid complaint that the user should not be able to kill his X server
and leave the console in a bad state (which is definitely not a Linux-
specific problem at all), then don't immediately think "Oh, we could use
GGI to fix this"!

Sure, if you have an ant infestation in your home, one fix is to nuke
half the continent to kingdom come, and then re-build your home in the
large crater that is left. It is a solution, and it obviously works.
Is it a _good_ solution? I don't think so, but some of the GGI
proponents seem to think it is quite reasonable.

The other solution is to take a can of RAID, and spray it in exactly the
right places. You don't need to demolish the neighbourhood, you only
need to put some bug-killer in the right place.

Quite frankly, I will continue to consider the "nuke the whole thing"
proponents to be of questionable intelligence until somebody shows me a
bug that is so fundamentally big that we'd better use a few tactical
warheads. So far people have shown me a lot of ants.

So please, people, consider just sending a bug-report to the XFree86
team, and explaining the issue, and maybe even giving them a hint on how
to fix it, for example. They may not listen to you, but _nobody_ will
listen to you unless you can come up with better arguments.

Linus

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu