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

[Alan Cox]

> 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.

Any kernel interface with a queue will lose events or block, its a
mathematical limit. A bounded length per consumer queue is really trivial
to implement thanks to the kfifo code and its easy enough to have an
overflow event to say "you didn't keep up, sort out your context"

Agreed entirely it needs a separate fd.

I wouldn't have expected there to have been many live queues in a system
- one for your management daemon, and perhaps one for someone debugging.

> 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.

That's not the usual definition of race free. It merely means that you
can ask 'was the data I used obsolete', not race-free which is 'is the
data I have valid'. Trouble is by then you've used it. That's my concern
about whether it is being done right.

> > > 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.
> > 
> > Try that with "keystrokes" for example. its a bogus argument.
> 
> Jeez. Kay's interface does not expose keystrokes. Just a simple integer
> which tells yu which VT is current.

Stop acting dumb for a moment, I was pointing out the generality of the
argument was daft.

> > Describe this permission management you are doing please.
> 
> 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.

So firstly you need to implement revoke.

That aside you still have the problem that you will lag in your
permission changes so if user B is quick they can get access to things
belonging to user A. No big deal for sound output but a bit bad for
reformatting his USB key.

We get what

	poll
	what tty
	tty1 - oh thats fred
	switch to tty2 bill

	set all the rights for fred
	Oh bugger while we've been remounting file systems (can take 30
	seconds easily) bill has been a bad boy (or just got fed up of
	the wrong music)

So yes it'll always run after the correct answer (which waitactive wont)
but I don't see how you can build a real permission model on it. I do see
how you can use it to get the right sound playing and the like which
waitactive can't do right. Furthermore you aren't going to be able to do
real permissions with it when you get revoke because at the point your
switching is actually a real permission boundary you need to be able to
have the daemon also lock the vt to stop changes. We do support that kind
of locking of vt switching, and in the past fifteen years it hasn't been
a big problem. In particular it does the relevant unlocking and the like
if the owner dies.

Your interface is also going to go castors up once we allow multiple
active vts at once belonging to multiple users. That's a limit which is
already becoming a bit of an embarrasment with the capabilities of the
current DRI.

I think I'd rather have a proper event kfifo device (which is a tiny bit
of code) and which can in future support multi-console stuff and which
integrates with the existing kernel vt switch locking when the user has
suitable rights and wants to do that.


Now if you got

	open /dev/vtmgr
	poll
	event structure

which behaved with the same behaviour as your magic sysfs hook off a
device file you would I assume be happy even though the data is just as
useless as your current scheme ?

It would however allow reporting of more things, allow us to go
multi-head without the API breaking (providing the messages are
sensibly designed) and support synchronous notification/approval which the
sysfs file won't and it would fix all the VT_WAITEVENT equivalent
functionality for all the potential users.

Not sure I'd want to allow more than one opener to do notify/approval
stuff.

Codewise its pretty trivial - misc device register, alloc a page sized
kfifo on open, free it on close, yank a kfifo entry on read, do poll
properly and stuff the messages posted down each open one.

Serious question - do we even need multiple openers. Your model for this
is a manager app which presumably can provide events to any other bit of
the desktop that cares and in fact probably should be the person doing
that so that it can sequence and control things cleanly ?

(we an always add multiple opener later)


Alan
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/