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.

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.

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

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