Re: tty: add 'active' sysfs attribute to tty0 and console device

[Lennart Poettering <mzxreary@0pointer.de>]

On Tue, 16.11.10 19:55, Alan Cox (alan@lxorguk.ukuu.org.uk) wrote:

> 
> > we always will apply the final result just fine, when stuff stops
> > changing. It's actually a nice feature and no a problem at all, that
> > we only see the most recent state.
> 
> Stuff never stops changing until the machine shuts down, its undefined.
> 
> > Sure, with the ioctl() we've seen many not interesting changes, but we
> > often miss the single one that is important -- the last last one. The
> > thing is that we don't need to sleep here and miss changes.
> 
> So we fix the ioctl interface, it's not exactly hard to do now is it.

Sorry, the WAITEVENT stuff interface you created is unusably broken:

  a) it's a sleeping ioctl which makes it unusable in anything but the
  most trivial applications, because most programs need to respond to
  more than once wakeup event. Of course, you can then introduce threads
  but that's horrible.

  b) It loses events, because events that happen after you woke up and
  before you go back into WAITEVENT are completely lost. And those
  events might actually be relevant, since they might be the most recent events
  that happened. And those tend to be ones that matter.

Kay's interface also drops events, but only historic events that happened
but aren't current anymore. And that's a good thing, because when you
track which VT is in the foreground for presentation, or for permission
management purposes then you care little of who else should have had
access in the past but didn't get it. You are only interested in the most
recent update, which is what Kay's interface gives you. 

Kay's interface is not intended to be useful for logging purposes. It is
useful to track VT changes for service activation, for permission
management.

> > It's a straight-forward and simple text interface that does all we
> > need to track console and vt changes.
> 
> Except that it doesn't address things like the permissions side of
> things.

Well, the suff it provides is purely informational. You cannot actually
influence the TTY in anyway, you can just watch which VT is currently
active.

I don't think that information should be protected more than
necessary. If 

> "We have an interface that doesn't quite work for our case and we think
> that is a bug" is not the reasoning behind writing a new random one with
> a totally disconnected permission model that doesn't work either.

I am sorry, but WAITEVENT doesn't work for *any* case. It is completely
broken. Have you actually ever tried to use it yourself? Do it. Write me
a race-free program with it that tracks VT switches and i'd be amazed!

> Fix the one we have.

Well, to fix the existing one, you'd a) have to turn it into something
with a pollable fd, and b) something that doesn't lose current
events. And voila, you'll have created Kay's interface.

Lennart

-- 
Lennart Poettering - Red Hat, Inc.