Re: INPUT_COMPAT_TEST

On 07/08/2011 03:37 PM, Dmitry Torokhov wrote:

quoted

quoted

We also have similar issues with uinput API and uploading force-freedack
effects.

Those are ioctl, though, if I read the code right, or did I miss
something obvious?

Ah, yes, indeed.

So the point still holds... you're right now using INPUT_COMPAT_TEST for
those, but what you *should* use is whether or not you were entered via
the compat ioctl entry point.

quoted

quoted

quoted

but it looks like input also
does things like change the format(?!) of sysfs entries, all of which
makes me very concerned.

Another historical unfortunate decision. /proc/bus/input (and later
added sysfs entries) export bitmaps in "compressed" form so that
userspace can not figure out the size of the segment (32 or 64 bit) on
its own so we have to convert to userspace size for longs.

"Compressed form"?  Could you give a concrete example?  They look like
they are emitted in text form.

We drop leading zeroes so if you get "1 0 0 1ffff" you do not know
the bit position of the most significant '1' unless we keep segments of
known size. Unfortunately we started with 32 bit segments on 32 bit
kernels and 64 bit segments on 64 bit kernels so we coudl not simply say
that we always split on 32 bit boundary when we discovered compat
problem a few years later.

Ah yes, it is the "binary output masquerading as text, so we end up with
something that is worse a mess than either" problem.

quoted

Do you have a program that someone could run to see the differences
between compat and non-compat paths?

Hmm, cat for /proc/bus/input/devices and sysfs nodes and evtest would
either work or give garbage if compat code woudl not work.

I'm desperately trying to come up with a solution which doesn't require
us to replicate every single system call (which is what relying on
is_compat_task() does -- it remembers the entry point used) in order
support one single misdesigned subsystem.  Do you have any kind of ideas
for what we might be able to do?

	-hpa