> >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.
Well, it is not trivial to fix.
> 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.
It'd need to communicate with the X server all the time about most of things
the X server does to precisely know about what state the display after the
server itself crashes is. For many cards it is not possible to just change
a videomode when you don't know what state (not just videomode) the card
is in.
> 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).
Myself I think it shouldn't be possible to make the system unusable just
by killing a process. Even if you have to be root for that.
> 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).
Which was never fixed for cards it can't be fixed on (Eg. Any S3 card with
older ICS clockchip, which are write-only, and thus the textmode can't be
saved to be restored.).
> 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".
True. I'm not an advocate of KGI/GGI itself, but I think I've thought
long enough to know the mode switching / memory mapping / DMA / interrupt /
generic accel support for the videocard in the kernel IS the only reasonable
way to make things work.
> 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.
It doesn't necessarily have to be EvStack, but, a generalized input device
subsystem would be good, and to prove that it's at least worth considering,
I'll just note that some of other unices use an approach like this.
> 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.
Yes, but for a long lasting annoying, but not critical imperfection there
sometimes isn't any other solution than a deep cut.
> 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"!
I just say, "Oh, we can't do this in userland!", because once you have
a driver in userland you can kill it, and leave the device in unusable
state.
> 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.
Graphic cards that use DMA and interrupts? Isn't that enough to see
that a kernel driver (at least for these, but why not to solve other
problems together with it?) is needed?
> 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.
There are bugs that can be solved by changing X. And there are those which
can't.
Vojtech Pavlik
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu