login
Search
commit be0d5f02c9194fe41c1aad11d7282db117bda938
Author: Kay Sievers <kay.sievers@vrfy.org>
Date: Tue Nov 9 18:53:59 2010 +0100
tty: add 'active' sysfs attribute to tty0 and console device
Userspace can query the actual virtual console, and the configured
console devices behind /dev/tt0 and /dev/console.
The last entry in the list of devices is the active device, analog
to the console= kernel command line option.
The attribute supports poll(), which is raised when the virtual
console is changed or /dev/console is reconfigured.
Signed-off-by: Kay Sievers <kay.sievers@vrfy.org>
diff --git a/Documentation/ABI/testing/sysfs-tty b/Documentation/ABI/testing/sysfs-tty
new file mode 100644
index 0000000..b138b66
--- /dev/null
+++ b/Documentation/ABI/testing/sysfs-tty
@@ -0,0 +1,19 @@
+What: /sys/class/tty/console/active
+Date: Nov 2010
+Contact: Kay Sievers <kay.sievers@vrfy.org>
+Description:
+ Shows the list of currently configured
+ console devices, like 'tty1 ttyS0'.
+ The last entry in the file is the active
+ device connected to /dev/console.
+ The file supports poll() to detect virtual
+ console switches.
+
+What: /sys/class/tty/tty0/active
+Date: Nov 2010
+Contact: Kay Sievers <kay.sievers@vrfy.org>
+Description:
+ Shows the currently active virtual console
+ device, like 'tty1'.
+ The file supports poll() to detect virtual
+ console switches.
diff --git a/drivers/tty/tty_io.c b/drivers/tty/tty_io.c
index c05c5af..be5ab4a 100644
--- a/drivers/tty/tty_io.c
+++ b/drivers/tty/tty_io.c
@@ -3232,9 +3232,45 @@ static int __init tty_class_init(void)
postcore_initcall(tty_class_init);
/* 3/2004 jmc: why do these devices exist? */
-
static struct cdev tty_cdev, console_cdev;
+static ssize_t show_cons_active(struct device *dev,
+ struct device_attribute *attr, char *buf)
+{
+ struct console *cs[16];
+ int i = 0;
+ struct console *c;
+ ssize_t count = ...On Tue, 16 Nov 2010 16:46:40 +0100 All the other vt interface code is in the vt driver, the ioctls for it are in the vt driver and a query about what is the active vt only has meaning within that context as you need to post a waitevent first to track changes during the query. So if you need a VT_GETACTIVE interface NAK this, its a nonsense interface Seriously what use is an interface that tells you "what the console might Please keep unneccessary reformatting patches out of code changes, submit What is the locking on tty0dev at this point ? Wrong place anyway - we have vt change notifiers that do this properly and can track other changes like console sizes, add and remove. See the VT_WAITACTIVE stuff How do you ensure fg_console returned to user space is right when the console can change during and after the call ? --
You mean the VT_WAITEVENT? Sleeping ioctls() can't be used. The time between the check for the current, and you go to sleep in the ioctl() for teh next is a window which isn't covered with such interface. And 'might have been' does not matter, it's fine. We just need change notification, and can query the actual vt again. Kay --
The only thing you need to add is VT_GETACTIVE, which is fine providing you know how to use it, but in both cases it is basically useless because by the time you've asked the question the answer is undefined. You can only use an interface of this type if you lock against VT changes, which is how the X interface works if you look at it. So what are you going to do with the return value from an interface which provide "what was the console, perhaps, at some point you asked but could even have been deleted, assigned to a different user, hot unplugged or moved to another framebuffer device by the time I answer" What is it for ??? --
It's for tracking changes. Every async event interface might carry values which are not true anytime after the event. But, unlike with the ioctl(), that does not matter for us, because changes are always signaled with poll() and there is no window between a check and the next wait-for-the-next-event which can't be covered. Sleeping ioctl()s like VT_EVENT can't be used to track the current VT because they might go to sleep() even when stuff has changed since the last check. We actually need to revert its use from ConsoleKit because it can't be fixed properly, and actually causes problems for people. It does not matter if things change at high frequency underneath us, 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. 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. It's a straight-forward and simple text interface that does all we need to track console and vt changes. Kay --
Except that it doesn't address things like the permissions side of things. NAK again "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. Fix the one we have. Alan --
Either you don't, or you just don't want to understand what all this So how do you think you'll fix it? I better don't get into your ioctl() business. Kay --
At what point do you think the current tty stops changing ? The only cases I can think of are shutdown, and when your own processes locks vt /dev/tty* and sysfs nodes don't track permissions, owner with each other, so you are providing interfaces that either expose information they shouldn't (which screen is valuable info in some environments), or don't expose info they should. Start by explaining why the current interface doesn't work for you, but in detail. --
Hmm, what do you mean? It's not the tty IO. It's only the VT switch, and this changes only when someone actually does the switch, like You think exposing the currently active VC is security relevant? We don't expose anything from the VC itself. We have this information all over the place in userspace. What exactly you think is the problem The sleeping ioctl() requires a dedicated thread in a service. Now we wake up and all the stuff that happens now is lost, so we have to check with another ioctl(), between this ioctl() and going to sleep again is a window we don't cover, we just go to sleep, even when something has happened. Poll() solves that by queuing the notification until it's retrieved. Kay --
Well, I find the informatoin who is logged in much more valuable then the information whether I am active or not. And the who is logged in Which is a feature, no a bug. It would be kinda messy if the service which manages device access based on whose session is active would always be forcibly stopped from doing so if somebody calls vhangup(). Lennart -- Lennart Poettering - Red Hat, Inc. --
On Tue, 16 Nov 2010 22:42:50 +0100 Well thats fine for your machine, what about the rest of us ? --
I think most people (except maybe you) find it more security relevant if it is leaked who's logged in and on which tty then it is to know whether that's the active session or not. And as long as we have no problem with letting everybody know who is logged in, and on which tty we shouldn't waste brain cells on discussing whether it is a problem if they also find out whether that login is currently active or not. Also, sysfs supports perms just fine. If you don't want people to see it, then just chmod 600 the sysfs file, and nobody can see it anymore. That's a trivial thing to do. It's a lot more difficult to hide who's logged in, since the user who is logged in takes possession of the tty file which everybody can see and stat(), even if not open(). This is really a pointless discussion. Security is not an issue here. Which tty is currently active is completely boring information, and the least we should think about. Lennart -- Lennart Poettering - Red Hat, Inc. --
Thge current kernel supports you not knowing who is using which console, furthermore there are environments where this is both used and the current console is *very* important information. The fact you lack the knowledge of such environments or even the wit to Wrong. That's the kind of sloppy attitude that causes bugs, poor code and security holes. It's the kind of arrogant "it only gets used like I say it does so screw the rest of you" attitude that the certain desktops are wrecked by. So we *are* going to discuss the security, we are going to discuss the permissions and we are going to discuss the permissions management model you are trying to implement because when we've done that there is a good chance of finding a model that a) works b) is secure and c) solves your specific problem case. Alan --
How would that work? Not giving a user ownership of the tty device? That would break like about every second program. It's too late for this. And anyway unless the kernel is patched you can even see who is running which process on the system. And now you become all nervous about telling people which tty is currently in the fg? Seriously? Security is a fog granade here. It's a non-issue. Also, afaics the current ioctl() interface you love so much works on any tty and gives you that information anyway, right? Some tty fd should be accessible by about every process and VT_GETSTATE on that and you have the same information -- and no further perm checking is done at all! So isn't Kay's approach much nicer, where you can actually protect this oh-so-precious information in a much tighter fashion thatn with normal ioctls! Lennart -- Lennart Poettering - Red Hat, Inc. --
Actually almost nothing in the OS cares about what another user is doing, I'm not particularly attached to the ioctl interface, and I'm not disagreeing with you that it needs redoing to actually be useful for what you want and for a lot of other cases. The question is what the resulting interface should look like so its useful for more than just your specific You need to have access to a console fd, which in that case is normally fine, but it is a weakness and one reason I know about that is because it has been complained about ! And as you say setting it to 0600 fixes that aspect. I've no problem with that either as SELinux rules can manage it effectively. Alan --
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 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 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 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. --
So those are both trivial enough to fix as far as I can see but by the No Kay's interface gives you some random reasonably recent answer that You wish to do permission management based upon stale unlocked data, yeah that sounds about the standard of some of the current shipping Which also doesn't work reliably and you want to use it for permissions management ! Describe this permission management you are doing please. Alan --
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 The POLLPRI bit is set until the moment you read the current VT value. Then it is atomically reset at the same time as your read(). At that time the VT info is up-to-date and the newest one. If it then changes again, the POLLPRI bit is set again, and the next time you call poll() you will be notified about that and wakeup right away. With other words: the moment you read the VT info from the kernel it is always the latest info available. And the POLLPRI makes sure that you will notice What matters is that we fix the perms before we inform clients about the VT switches. It does not matter that change the perms before the kernel officially went through with the VT switch. Or in other words: delivery of notification about VT switches can be done asynchronously between the kernel and the perm manager. But from the perm manager to the services we need synchronous notification. (Or, alternatively, they Jeez. Kay's interface does not expose keystrokes. Just a simple integer 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. Lennart -- Lennart Poettering - Red Hat, Inc. --
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 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 Stop acting dumb for a moment, I was pointing out the generality of the 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. ...
>>>>> "Lennart" == Lennart Poettering <mzxreary@0pointer.de> writes: Lennart> When two users A and B are logged in, on tty1 resp. tty2, Lennart> then as long as tty1 is active user A should get access to Lennart> the sound card, usb key, .... As soon as we switch to tty2 Lennart> user B should. Hmm, it's an interesting idea, and I run into this myself when my son logs into my desktop as himself and wants to hear sound. But I wonder how do you handle the case where there are multiple seats (KVM+S) on one system? Do you have a mapping table? John --
So I change to tty1, plug in my 8G USB memory stick, and I have access to it. I start copying something big to it, and change to tty2 to do something else while the long copy happens... ... and my copy craps out because tty1 lost access to the USB. Brilliant.
Brilliant conclusion. If you have mounted it, you own it. But you can not make your inactive session mount another new one. It's like this since ages. Hint: try stuff before hitting reply too fast. :) Kay --
Except during the window when screen switching, or of course you could just ssh in remotely and gdb or similar a process with it as controlling tty running on your console and issue a vt switch back, then mount it. Ironically the move from a root owned X server has made that much simpler to automate, although it was always possible. Given you can often guess from the idle data if the victim has gone away from the box it's not ideal. Even better any mess will appear on my display and get hidden when I flip it back. The only way to stop that is to make use of the display locking facility which takes us back where we began in saying that a usable interface is going to need to lock the display. At that point the current console owner has to choose to allow the console to be switched which can be limited effectively to physical console access and done synchronously. In turn that means to abuse it I already have physical access to the other users key so could just as easily steal it and the software security is therefore sufficient. Alan --
Ok, we are way-off-topic here from the original points. Which are: - the existing ioctl is broken and no userspace program can use it properly, so it might as well be removed. - Kay's patch is one proposed solution for what userspace is wanting to learn about ttys. Werner's is another one. So, what to do? I can do any one, or multiple things from the following options: - disable the existing ioctl to return an error so that no new userspace program starts to use it thinking it is valid - accept Werner's patch for those who like proc files - accept Kay's patch Any suggestions? thanks, greg k-h --
Maybe this is not so surprising, but I definitely want item #3 from the list. I am against #2, since #1 is a much nicer solution, and having both would be needlessly redundant. And #1 would be a good idea. Lennart -- Lennart Poettering - Red Hat, Inc. --
I think you mean s/1/3/ here, right? And yes, having both will be redundant, and Werner seems to not be responding anymore as to why he feels his patch is somehow still needed given that Kay's patch accomplishes the same thing from what I can tell. thanks, greg k-h --
Yes, of course. Sorry for the confusion. Lennart -- Lennart Poettering - Red Hat, Inc. --
I'm still reading and I'm wondering about this discussion. The only
thing I'd like to be able is to detect all ttys used for the system
console even if not a VT (not having a VT but several other consoles
is the most pressing case e.g. on s390 or zSeries) and this without
forcing (and maybe stealing) the controlling tty on the system console
to be able to detect the primary tty/console.
The primary tty marked with CON_CONSDEV and normally the first in
console_drivers. This can be done with Kay's patch as well as with
my approach. And both approaches do have the advantage to become
the full list of consoles which will help me to extend e.g. sulogin ...
The only advantage of my approache in comparision to Kay's one is that
the remaining console flags become visible for normal user space.
This was an idea of Randy Dunlap otherwise my patch would provide
the same information as the patch of Kay.
Maybe Kay could extend his patch in that way that the flags and the
facilities (having device, read, write, and unblank) are also shown
in the new file /sys/class/tty/console/active ... but maybe Randy
could says a few words for what this is usable.
Werner
--
System V style init programs - http://savannah.nongnu.org/projects/sysvinit/
--
What do you mean by console in this context The console in printk context and the "console" in "active vt window" are unrelated concepts with the same name, so its a bit confusing to follow The system console does not even need to be a tty device, and on many embedded devices is not (it may for example by a RAM buffer not wiped over reboots or it may be jtag or MIPI trace ports. "tty0" is *currently* a shorthand for "the VT the keyboard/display are showing". That's a shorthand that in itself will make no sense in future. Alan --
Example: running a boot script on /dev/console and after fsck
sulogin has to called to be able to asked the system admin.
Now the question is which console device the system admin is
I'm aware of. For using tty devices of the system console it requires
to have e.g. with my patch:
bash> cat /proc/tty/consoles
tty0 -WU (ECp) 4:7
the `W' flag for write and the major:minor pair, beside this the `U'
flag indicates the tty can do an unblank operation, the `-' shows that
there is no read operation (never seen such a console tty). On an other
system here I see:
bash> cat /proc/tty/consoles
ttyS0 -W- (ECp) 4:64
tty0 -WU (Ep) 4:1
which I'm using in user space with
dev_t dev = 0;
FILE * fc;
if ((fc = fopen("/proc/tty/consoles", "r"))) {
char fbuf[16];
int maj, min;
while ((fscanf(fc, "%*s %*s (%[^)]) %d:%d", &fbuf[0], &maj, &min) == 3)) {
if (!strchr(fbuf, 'E'))
continue;
if (strchr(fbuf, 'C')) {
dev = makedev(maj, min);
break;
}
}
fclose(fc);
}
to detect the primary console device here.
Werner
--
"Having a smoking section in a restaurant is like having
a peeing section in a swimming pool." -- Edward Burr
--
Ok that is a rather nebulous concept for embedded. The answer probably Why not just open /dev/console ? Alan --
How can I detect the major and minor of the primary console device
of /dev/console without controlling tty? Even if my old blogd
and the bootlogd(8) of SysInitV using TIOCCONS are outdated by SystemD
the question before doing the TIOCCONS is which is the primary console
device to e.g. create the device node in initrd or for bootlogd(8)
to write a copy of the console messages back to the original
primary console (and the other console devices).
Werner
--
"Having a smoking section in a restaurant is like having
a peeing section in a swimming pool." -- Edward Burr
--
In the general case you can't - because a console may not have a tty. Quite a few don't. For the cases where one has a device I can't see a clean way to do it as an fstat on the console device will give you the console major/mninor and some code depends upon that. The iniability to get it is clearly a flaw and you need the sysfs link or a sysfs list of consoles (again remembering many of them won't have a tty For init it is /dev/console as opened at boot time and passed to the initial user init task but with no nice way to work back to a device node. Incidentally the primary console (as in printk) can be accessed as a tty via the ttyprintk driver which got added recently because embedded people wanted to use the printk interface as a (write only) tty console as well. --
ACK ... nevertheless sometime it could be very useful to be able to Even with this case and IMHO a copy of all system console messages Currently the bootlogd(8) or blogd(8) parse the kernels command line and if available do an ioctl TIOCGDEV (not supported by the upstream kernel), then create a pty/tty pair, do an ioctl TIOCCONS to forward the system console to the created tty, now both daemons can parse all console messages to write out logs and write all copies to the former devices node(s) (compare with http://lkml.org/lkml/2000/12/15/160 I've seen that in the changelog of the kernel ... maybe this would a good replacment for the /dev/kmsg redirect of stdout/stderr in initrd. Werner -- System V style init programs - http://savannah.nongnu.org/projects/sysvinit/ --
So perhaps the vendors using TIOCGDEV could get off their collective backsides and submit it upstream ? Alan --
That I've tried 10 years before. If you think it's worth to retry
you may have a look on the attachment only for a short review
Werner
--
System V style init programs - http://savannah.nongnu.org/projects/sysvinit/
Heh, that's what started this whole thing :) I objected to TIOCGDEV going in as it seemed that only suse needed it for their boot sequence, and no other distro did which implied that it really wasn't necessary. I'm still not convinced it is needed, and the many thousands of booting systems out there without it seem to confirm it... thanks, greg k-h --
Uhmm ... just to say it: I've been asked by Fedorea people and also by Debian people why I had not submitted this patch and I've told them that I had it done long time ago ;) It seems to me that there is some demand but most user space monitoring applications uses workarounds (AFAICR plymouth uses hard coded VT for boot and shutdown). Werner -- System V style init programs - http://savannah.nongnu.org/projects/sysvinit/ --
I think the market won the argument on this one - so please yes - submit it. --
Just to be sure, do you have noticed my mail with the ID <20101119170736.GA4177@boole.suse.de> which had attached the the patch? Werner -- System V style init programs - http://savannah.nongnu.org/projects/sysvinit/ --
I'm pretty sure such flags, if they are meant to be exported to userspace (which I have no good idea about) belong to the individual devices, and not in the 'active' file. We surely can do that, if that fits into the general picture. You could poll(console/active) for changes, get the list of devices, and look at them individually. poll() will tell you when you dynamically need to adapt your service. Kay --
You can use it happily for various things providing you hold the vt switch lock. It's not a very good API and wants something doing about it. However we can't deprecate it using either of the proposed patches Kay's patch is useless. As we've demonstrated by as you call it "going off topic" it can't actually provide a credible security model. Its providing a variable without holding the locks that make the value meaningful. Thats as basic an error I can think of. We wouldn't accept kernel code which did mutex_lock(&foo->lock) temp = foo->only_valid_under_lock; mutex_unlock(&foo->lock); return temp; /* ma invalid by now */ especially when it was going to be used for permission management. We'd call it a bug. So why are we proposing to add an API that does exactly None of the above. In fact the current situation is better than either of the patches because it's equally broken and involves no more broken APIs ! Doing it right means: - deprecating the existing ioctl (because it's a dumb interface and Kay is right about that) - adding a proper event device which is pollable and returns the same events (and more) using a small kfifo queue. Trivial to code and will not add another API we'll need to deprecate again the moment anyone wants to use it. - support synchronous switching by that interface or verify the existing vt locking interfaces will do the job in conjunction with it. Kay's approach doesn't solve three things - You can't use the data to implement proper secure desktop switching - It doesn't support moving to multiple active vts at a time - You can't deprecate the wait event interface unless you replace all the features of it that people use (eg resize events) So we will be back here again doing the same thing deprecating Kay's interface if we go that way. Having an event device actually lets us solve the problem properly, and if we are careful about the message formats cover the fact the KMS folks and others want multiple ...
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 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 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 ...
> All this is just no real issue for us. This is not about security in
The kernel isn't "for us", it has to cleanly solve the general purpose
cases for all the usage cases. That varies from home type desktops where
security isn't so important to secure installations where you damned well
Except we've already shown that is false for the more security concious
Of course you could fix it, you make the desktop change in that case
synchronous. Most of what is needed is already there.
Now I don't care whether your particularly desktop bothers to or not,
It means you have the option to do so. Clearly at boot time it would get
a bit silly to do that. So for your use case you'd not ask for
Of course I'd point out every X based VT switch is currently synchronous.
I don't believe X has any hooks for doing stuff mid switch via helpers
There are lots of interfaces where single opener makes total sense so
that's not a good generalisation. I would agree the vt interface is one
Fine so don't choose to use it. Oh wait you already are as you use the X
No - the problem you have is that the kernel VT layer is two things
1. It's a VT100 emulator
2. It's a display surface and set of input bindings.
Plug two keyboards into a PC and right now we fail to support two
keyboard/two mouse/two screens even though all the hardware can do it. In
that situation the VT interface is in many ways a legacy element but it
ought to work, and the blanking and screen switching create a nasty mess
if you try and hack around it and the notion it keeps of the display
That's relatively easy to transition we add a
struct all_the_crap_i_need_to_round_up {}
and reference off it, then allow multiple instances. Been there done that
I don't think it is looking at the code. If I thought otherwise I'd be
less jumping up and down about it. We already have an abstraction which
is an event (ie message) in the code and thanks to kfifo the rest is
An API that forces you to block VT switches when you ...
