> All this is just no real issue for us. This is not about security in
The kernel isn't "for us", it has to cleanly solve the general purpose
cases for all the usage cases. That varies from home type desktops where
security isn't so important to secure installations where you damned well
better get a console switch right.
Except we've already shown that is false for the more security concious
case, so we need the kernel ability to handle both.
Of course you could fix it, you make the desktop change in that case
synchronous. Most of what is needed is already there.
Now I don't care whether your particularly desktop bothers to or not,
but I do care that the interface in question is general purpose.
It means you have the option to do so. Clearly at boot time it would get
a bit silly to do that. So for your use case you'd not ask for
synchronous switching.
Of course I'd point out every X based VT switch is currently synchronous.
I don't believe X has any hooks for doing stuff mid switch via helpers
but I'd have to check with X hackers on that.
There are lots of interfaces where single opener makes total sense so
that's not a good generalisation. I would agree the vt interface is one
where you might want multiple users, but that is easy to do.
Depending where you do the VT synchronous handling.
Fine so don't choose to use it. Oh wait you already are as you use the X
server.
No - the problem you have is that the kernel VT layer is two things
1. It's a VT100 emulator
2. It's a display surface and set of input bindings.
Plug two keyboards into a PC and right now we fail to support two
keyboard/two mouse/two screens even though all the hardware can do it. In
that situation the VT interface is in many ways a legacy element but it
ought to work, and the blanking and screen switching create a nasty mess
if you try and hack around it and the notion it keeps of the display
surfaces.
That's relatively easy to transition we add a
struct all_the_crap_i_need_to_round_up {}
and reference off it, then allow multiple instances. Been there done that
several times.
I don't think it is looking at the code. If I thought otherwise I'd be
less jumping up and down about it. We already have an abstraction which
is an event (ie message) in the code and thanks to kfifo the rest is
noddy too, kfifo even does all the locking needed.
An API that forces you to block VT switches when you don't want it is as
broken as an API which only supports async.
I don't for one minute intend to propose an API that forces synchronous
on you, or in fact to propose anyone implements multi-way synchronous vt
switch management first time around the implementation.
Alan
--
