|Kay Sievers||Nov 16, 2010 7:46 am|
|Alan Cox||Nov 16, 2010 7:56 am|
|Kay Sievers||Nov 16, 2010 8:12 am|
|Alan Cox||Nov 16, 2010 9:14 am|
|Kay Sievers||Nov 16, 2010 10:51 am|
|Alan Cox||Nov 16, 2010 11:55 am|
|Kay Sievers||Nov 16, 2010 12:15 pm|
|Alan Cox||Nov 16, 2010 12:48 pm|
|Kay Sievers||Nov 16, 2010 1:28 pm|
|Lennart Poettering||Nov 16, 2010 1:35 pm|
|Lennart Poettering||Nov 16, 2010 1:42 pm|
|Alan Cox||Nov 16, 2010 2:51 pm|
|Alan Cox||Nov 16, 2010 2:55 pm|
|Lennart Poettering||Nov 16, 2010 2:58 pm|
|Alan Cox||Nov 16, 2010 3:04 pm|
|Lennart Poettering||Nov 16, 2010 3:10 pm|
|Lennart Poettering||Nov 16, 2010 3:18 pm|
|Alan Cox||Nov 16, 2010 3:45 pm|
|Etched Pixels||Nov 16, 2010 3:49 pm|
|John Stoffel||Nov 17, 2010 8:31 am|
|Vald...@vt.edu||Nov 17, 2010 2:00 pm|
|Kay Sievers||Nov 17, 2010 3:39 pm|
|Alan Cox||Nov 17, 2010 3:56 pm|
|Greg KH||Nov 17, 2010 5:27 pm|
|Lennart Poettering||Nov 17, 2010 5:48 pm|
|Greg KH||Nov 17, 2010 5:52 pm|
|Lennart Poettering||Nov 17, 2010 6:28 pm|
|Alan Cox||Nov 18, 2010 2:14 am|
|Dr. Werner Fink||Nov 18, 2010 2:59 am|
|Alan Cox||Nov 18, 2010 3:23 am|
|Kay Sievers||Nov 18, 2010 3:54 am|
|Kay Sievers||Nov 18, 2010 4:03 am|
|Dr. Werner Fink||Nov 18, 2010 4:12 am|
|Alan Cox||Nov 18, 2010 4:57 am|
|Alan Cox||Nov 18, 2010 5:00 am|
|Dr. Werner Fink||Nov 18, 2010 5:13 am|
|Alan Cox||Nov 18, 2010 6:41 am|
|Dr. Werner Fink||Nov 19, 2010 5:21 am|
|Alan Cox||Nov 19, 2010 7:46 am|
|Dr. Werner Fink||Nov 19, 2010 9:06 am||.tiocgdev|
|Greg KH||Nov 19, 2010 10:02 am|
|Dr. Werner Fink||Nov 19, 2010 10:41 am|
|Alan Cox||Nov 20, 2010 4:39 am|
|Dr. Werner Fink||Dec 1, 2010 3:15 am|
|Dr. Werner Fink||Dec 1, 2010 4:31 am||.tiocgdev|
|Dr. Werner Fink||Dec 3, 2010 3:47 am||.Other|
|Subject:||Re: tty: add 'active' sysfs attribute to tty0 and console device|
|From:||Alan Cox (al...@lxorguk.ukuu.org.uk)|
|Date:||Nov 16, 2010 3:45:11 pm|
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)