Thread (13 messages) flat view 13 messages, 3 authors, 2011-09-07

INPUT_COMPAT_TEST

From: "H. Peter Anvin" <hpa@zytor.com>
Date: 2011-07-08 18:45:46

Hello,

I'm trying to figure out what system calls can actually invoke code that
depends on INPUT_COMPAT_TEST, and in particular which of those changes
actually matter.

The input system and seccomp are the *only* arch-neutral subsystem in
Linux which appear to trigger on if we are in compat mode, and this is
causing some serious consternation in trying to freeze the proposed x32
(32-bit x86-64) ABI.

I would really like to understand if that dependency can be eliminated
or mitigated; as it currently sits we may need an entirely separate
system call table *just to support the input system*.

The problem is that I am personally not familiar enough with the input
subsystem to know what the dependencies are.  ioctls are not an issue;
there is already an entire infrastructure to handle compatibility ioctls
(and that infrastructure should be used!), but it looks like input also
does things like change the format(?!) of sysfs entries, all of which
makes me very concerned.

Any help in creating an inventory for this would be appreciated.

	-hpa
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help