On 07/08/2011 01:46 PM, Dmitry Torokhov wrote: > > One such place is evdev read/write - unfortunately "struct input_event" > was not created 32/64 bit safe so we need to mangle it when running 32 > bit userspace with 64-bit kernels. See drivers/input/input-compat.c. > So these are actually present on all the read/write path system calls. That is truly awful. Do you happen to know if there is any kind of passing around of file descriptors, or if this could perhaps be tied to file descriptor state. > 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? >> 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. Do you have a program that someone could run to see the differences between compat and non-compat paths? -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
