Messages in this thread | | | Date | Wed, 22 Jul 2009 13:14:52 +0200 | From | Lennart Poettering <> | Subject | Re: [PATCH] vt: add an event interface |
| |
On Tue, 21.07.09 17:32, Alan Cox (alan@lxorguk.ukuu.org.uk) wrote:
> > > Sounds good to me. Though tbh, in my eyes the "proper" fix for this > > whole problem would be something which would enable userspace to > > poll() for VT changes. Having blocking ioctl()s still requires most > > The question there is what device do you poll(). It's easy enough to > magic up a separate vtevent device I guess.
Hmm, maybe we could just use the usual console devices and use SIGERR or SIGURG or something like that to signal those events? And then have an ioctl() to actually read them?
> > But OTOH I guess 2 threads are still better than the old situation > > requiring processes to run 64 threads for listening for VT changes. > > > > Oh, and one more note: instead of padding the struct it would probably > > be more future-proof to simply pass the struct size in addition to the > > struct to the ioctl(). > > Padding is a lot simpler and less likely to cause bugs later > (typecasting, mischecking of sizes etc). For the kernel I favour > simplicity. A vtevent poll/read interface would be even cleaner so I will > think about that a bit further.
But this isn't a kernel-internal iface, but something exposed to userspace. Userspace interfaces should be designed cleanly and future-proof. And padding structs is just painful and unflexible, since you might end up not reserving enough space for your future extensions, however until those extensions actually happen you always pass uneeded memory to the kernel.
But uh, then again, everything's better than the current situation. As long as we get something that doesn't require 64 threads for watching VT switches I am happy.
Lennart
-- Lennart Poettering Red Hat, Inc. lennart [at] poettering [dot] net http://0pointer.net/lennart/ GnuPG 0x1A015CC4
| |