Re: [PATCH] vt: add an event interface

[Alan Cox]

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

> userspace applications to spawn a thread for doing that since usually
> they are not exclusively waiting for VT events, but also for dbus
> requests or some other events.
> 
> 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.

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/