On Tue, 16.11.10 22:56, Alan Cox (al...@lxorguk.ukuu.org.uk) wrote:

Trivial enough to fix? No it isn't. We tried to come up with a sane fix for the current ioctl() iface, but it's not feasible. a) is unfixable anyway without some kind of additional fd, since the tty fd is not really something you want to overload with new POLLxxx events. For b) you either need a per-consumer queue, so that no events are lost. That is cumbersome, and would add a massive amount of code to the kernel. Or you need some kind of atomic extenstion a la "wait only if this information is still current". Which would work for our use case but still eat events that happen between the WAITEVENT calls. Or you would have to do this synchronous, which would basically allow userspace to block VT switches and the kernel indefinitely. Which is dangerous.

The POLLPRI bit is set until the moment you read the current VT value. Then it is atomically reset at the same time as your read(). At that time the VT info is up-to-date and the newest one. If it then changes again, the POLLPRI bit is set again, and the next time you call poll() you will be notified about that and wakeup right away. With other words: the moment you read the VT info from the kernel it is always the latest info available. And the POLLPRI makes sure that you will notice it isn't up-to-date the moment you enter poll() again. Race-free.

What matters is that we fix the perms before we inform clients about the VT switches. It does not matter that change the perms before the kernel officially went through with the VT switch. Or in other words: delivery of notification about VT switches can be done asynchronously between the kernel and the perm manager. But from the perm manager to the services we need synchronous notification. (Or, alternatively, they just use inotify on the device nodes, which in fact many already do).

Jeez. Kay's interface does not expose keystrokes. Just a simple integer which tells yu which VT is current.

When two users A and B are logged in, on tty1 resp. tty2, then as long as tty1 is active user A should get access to the sound card, usb key, .... As soon as we switch to tty2 user B should.

Lennart