On 2010-11-18, Alan Cox <al...@lxorguk.ukuu.org.uk> wrote:

All this is just no real issue for us. This is not about security in the sense of untrusted users being able to do something they couldn't do already, it's about passing the currently active user _some_ additional rights.

And if that user goes inactive there will always be a window where this user keeps some rights it had while active. There is always some kind of overlap, and even if we had revoke() we probably couldn't it for many reasons. Soft hand-over is the expected behavior. But the poll() will still show us that *something* has changed, and it's all we need to know to switch to the new user.

Synchronous interface means we block the VT switch until we have handled the event in userspace? We have several in-kernel VT switches during suspend-resume and such. I really don't think this will want to wait for userspace to do random crap in /dev? :)

We also never want single-use interfaces again. It's a pain when we need to switch to some new way of doing things,a nd need to run two services during the transition period. It is also always handy for debugging. We will not use any single-user-subscribe interface. It's an absolute requirement in the Linux eco-system not to block kernel interfaces with a running service, otherwise we end up with the /proc/acpi/* nightmare.

So if we have multiple subscribers, we need for all subscribers to finish userspace handling and let all other block in the VT switch ioctl()?

That all sounds nice to have for some tasks, sure no doubt, but it sounds pretty complicated/fragile for what we need to do. We are fine so far with the async behavior.

As far as I know, the future is VT-like stuff in Wayland-like things using a pty, and not legacy kernel-based VTs at all. They even think to leave all kernel VT stuff behind, because there are too many assumptions about, and they don't fit into the modern world of internationalization key/font-handling anyway.

I also see problems with a lot of compat stuff that is based on fg_console, and ...

And last, we could just have more than a single name in the 'active' file, if that really will ever happen, which I seriously don't expect.

I'm not against this, it might be what others are looking for. We could also use that, even when it's 100 times more complicated than the simple poll()able text interface.

As long as we can have multiple subscribers doing the same thing, and have a way not to block VT switches, but receive all this asynchronously.

I just expect a ton of problems if we now start making VT switches block, which they never did before.

Kay