Re: console plans

[Roland McGrath]

> Ok, I understand if that is the current goal, but I think the Right
> Thing should (1) behave in a sane way if the X server is kill -9:ed
> (i.e. cleanup bound to a no-senders notification somewhere), and (2)
> support arbitrary frame buffer applications in a simple and robust
> way.

I think X can be considered an arbitrary frame buffer application, and
there should just be a single simple and robust way to make sure this is
right.  For friendly switches, the VT synchronization interfaces designed
for X suffice.  Forcible switches are always a last resort that may
permanently screw the state of the program that you switched away from.
Doing that on the last close of a VT seems fine.

> I.e. the responsibility for sane gfx state should be in some
> privileged process. A non-privileged user should not be able to shoot
> it down (but he should still be able to kill his own X server, and
> certainly his fb applications, and perhaps even his own console).

A more complex idea that just occurred to me to truly improve robustness
would be to enforce io access only for the properly switched-to vt.  That
would be a reason to have a hairier io port access interface.  It would be
ideal if a Hurd interface through the particular vt gave you an individual
port that you could pass to the kernel to enable io access.  Then a master
control interface would dynamically disable the access imputed by a
particular port, so that in vt switching the console server made only the
port gotten from the active vt able to do video io.