> There's another problem - the way that VT_SETMODE works is that you call
> VT_GETMODE, change the values that you want, and call VT_SETMODE.
> You need a VT_GETMODEX along the same lines as VT_SETMODEX.
I'm not sure why VT_GETMODE call is required. Why don't X just set all
fields of that structure? I think they do. So why do they need GETMODE
if they just overwrite everything?
> Are you indending to address the reliable VT_ACTIVATE issue?
> At the moment, VT_WAITACTIVE sits inside a loop in vt.c until the
> right VT is selected.
Do you see any problem with it? It seems to me that current
implementation is pretty much ok. Yes, you are right, it is possible
to get few unneccessary wakeups each time console is toggled, so you
have unneccessary overhead of 4 or so schedules [worst case]. Does it
looks like problem to you?
> (IMHO, VT_WAITACTIVE should return 0 if fg_console==arg, even if
> vt_waitactive returns -1 since it has acheived its goal of changing VT.)
vt_waitactive could return -1 only because there is signal
pendig. Unless I'm missing something. And if you got signal, you are
probably not on right console, because otherwise you would be woken
sooner.
Pavel
-- I'm really pavel@atrey.karlin.mff.cuni.cz. Pavel Look at http://atrey.karlin.mff.cuni.cz/~pavel/ ;-).- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu