Re: GGI and cli/sti in X

Andreas Kostyrka (andreas@rainbow.studorg.tuwien.ac.at)
Sun, 29 Mar 1998 09:28:47 +0200 (CEST)

On 29 Mar 1998, Linus Torvalds wrote:
> 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.
You can't kill the X server as normal user today either, because it
normally needs to be root so or so. That's not the point.
Doing a kill -9 on any process on the system is legal. Right?
(At least as root.)
So what does it stop me to kill -9 both processes? And
while any oldtime user will not do this by hand, this may
happen with new ``admin'' users (Windows-convertides, that haven't
got it, that Linux is not 100% perfect in all departments yet), and
by some stupid script, that would have to know about Xservers, svgalib
programs, etc.
>
> 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.
kill the waiter, and kill then the X server.
>
> 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
I see. Why then can't I kill pid 1? *wonder*
But it still can be killed by some overjealous resource reclaiming script
:(
> 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).
It just doesn't solve all problems with the gfx subsystem.
You have also to take into this console level programs. (If this is
a good thing, that's another thing, but there are chipsets that
can only run fullspeed 3d with fullscreen :( )
>
> 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
Boy, this becomes difficult to a simple CS major as me.
1.) God is it difficult to argue with a halfgod, that got some
misconceptions :( *g*
2.) It hasn't to be called GGI. It can be also something else that
does only half of the stuff, like the ones associated with stability.
3.) Another scenario: Xserver hung, system dead. I know X server bug.
Go fix it. Right. But I'm still here with a newbie freshly converted
from HellOfGates, because Linux is ``so'' stable.
And here your proposition with the small wrapper doesn't help
anything, right? I mean, X has still it's raw key mode, right?
> 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".
Ok, start a series of X servers, and than randomly kill them -9 (from a
network *g*). Then demonstrate how you gain console access.

> 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.
Absolutly right. (To the 100s of other solutions.) But fixing it small
without a greater concept is what created a monster like Win95.

> 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.
Hmmm, if I remember right, the SCSI layer was also rewritten sometime from
scratch. It also had only some minor stability problems in general.
Or take the network layer. (I remember the days when this was also
replaced.)
>
> 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
Ok, than initiate something of your choosing. I'm not fixed on GGI, I'm
fixed on something stable first.
> 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"!
Nope. But proposing a guarding process to circumvent kill -9 sounds not
very solid to me. (It's just cries race condition, and work only depending
upon timing.)
>
> 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.
I see. Let me take different analogy: You've got some SMALL injury, and
even today, doctors would probably ampute your arm, IF NEEDED, so
you can live. It's also something very small, just some bacteries in small
number, that get to your blood, and you still have one arm less
afterwards, if you are unlucky :(

> 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.
Hmmm. I'll have to invite Mr. Torvalds to do the bug raiding at home here.
(In most cases you just get RAID resistent bugs :( *g*, or to take it
to a software analogy: You fixes teardrop #1, than comes boing (aka
teardrop #2), and you fix again.)

> 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.
The problem with ants is that, you have to kill their home, or else
they will show up every time again. And yes, if their home is your house's
fundaments, than one solution is the ``nuke-in-small-scale'' the house.
It may be the more expensive solution in short, but may be cheaper and
better in the long term. :(
>
> 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
Ok. So I've got a S3V/DX P100 box, that just locks up randomly on
server downshut. The whole box is dead. (No network, etc.) So WHAT should
I write as a bug report? No dumps, no debug output, etc.
And to make it more difficult, the box is with a client :(

Andreas

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