Hello everybody ...

I just got a new idea on how to solve the problem of safe vt-switching.

As we cannot reliably get swappable user-space memory from an interrupt-
environment and do not want to waste unswappable kernel memory for a
potentially huge amount of graphics mem, we currently rely on Linux's
default vt-switching scheme :

We set the tty to VT_PROCESS mode which will cause the kernel to send a
signal when a VT-switch request is received.

The controlling process will have to respond by issueing an ioctl to the
VT to allow the switch.

The problem arises when this ioctl never comes - be it due to an ill-behaved
application (which blocks the signal or simply doesn't send the ioctl)
or because the application is stuck in some uninterruptible state for a long
time (like when rewinding a tape).

So the idea is simply to use a well behaved application that does neither
ignore the signals it gets nor go into uninterruptible sleep for storing 
away the screen. This could be a daemon running as root that will be 
notified when a vt-switch occurs.

If the daemon dies we can simply revert to stopping applications that are
switched away. If somebody sends them a CONT they will segfault on the next
framebuffer access ...

The remaining problem is how to give the memory image from this daemon to
the app, when the app wants FULLBACKGROUND_MODE i.e. wants to continue
running and drawing in the background.

As we currently use shared memory for this problem anyway, we could still
do this:

The next framebuffer-access would trigger a sigsegv, as the driver sees that
the vt is switched away. The process could react on that and issue the
commands that are now in the vt_relsig handlers (munmap,shmat) to map the
real shared mem to where it belongs.

The same procedure will happen, when the screen comes back again. After our
trusted application has restored the screen it will destroy the shared
memory area thus causing a segfault on access again, so we can mmap the
video buffer again.


So - what do you think ? Is this a possible solution ? I think we could
get rid of the necessity to patch the kernel this way ...
Did I miss something ? What could be done better ?


Longing for your comments ...

Andy
