linux-kernel - Re: [PATCH] vt: add an event interface

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Date:	Wed, 22 Jul 2009 13:14:52 +0200
From:	Lennart Poettering <mzxreary@...inter.de>
To:	Alan Cox <alan@...rguk.ukuu.org.uk>
Cc:	linux-kernel@...r.kernel.org
Subject: Re: [PATCH] vt: add an event interface

On Tue, 21.07.09 17:32, Alan Cox (alan@...rguk.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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/