On 07/08/2011 03:37 PM, Dmitry Torokhov wrote: >> >>> 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. >> >>>> 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. >> >> 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 -- To unsubscribe from this list: send the line "unsubscribe linux-input" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
