Re: Supporting multiple keyboard

[Steffen S. <s.s...@ph...>]

Petr Vandrovec wrote:
 
> On  8 Jun 00 at 9:51, James Simmons wrote:
> > > Are you sure that it is so big security hole?
> 
> > Yes :( Remeber the video memeory is shared with all VCs allocated to it.
> > Each VC has it own text buffer which make sit safe to have different apps
> > writing on different VCs at the same time. Any changes the frmaebuffer
> > mapping makes effects all the VCs attached to it. A good example is I use
> > Mesa-GGI and when I VT switch it works right. By if I VT switch back and
> > forth very rapily it locks my machine. The text buffer and framebuffer
> > contents get scrambled.
> 
> Locking machine is not security hole... It is bad bug in software...

The question is which software is to blame for the bug. The kernel for not
using a rock-solid locking mechanism? The application(s) for having to
implement independent device driver instances touching the same hardwae
in preemptive code sections?

> > > You started processes on
> > > both VT's, if you were allowed to switch them...
> >
> > This is no problem if both process are text console programs since they
> > have seperate text buffers.
> 
> If they are graphics programs, they must either explicitly disable switching
> or they must be able to handle switches correctly.

Even if they handle switches 'correctly' from a software-theoretical point
of view they could get scheduled in the middle of setting up the hardware.
This can be sufficient to lock up the machine such that only a cold-boot
can recover.  And it is more likely if you 'stress' the machine by rapidly
changing the virtual terminals. The only reason Linux came away with
this concept so far is that console switches are rare events.
Scheduling or suspending (at user's request) applications using DRI is not,
and I wonder how the DRI developers intend to fix that cleanly.

			Steffen

_______________________________________________________________________________
Steffen Seeger                              mailto:se...@ph...