Messages in this thread | | | Date | Sun, 29 Mar 1998 11:26:25 +0200 | From | Vojtech Pavlik <> | Subject | Re: GGI and cli/sti in X |
| |
On Sun, Mar 29, 1998 at 02:27:30AM +0000, Linus Torvalds wrote:
> >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
| |