lkml.org 
[lkml]   [2004]   [Jun]   [3]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
Subjectinput_event size mismatch between 64bit kernel and 32bit userland ...

Pavel Kiryukhin discovered this problem while he is developing
64bit MIPS kernel. With his permission I am forwarding this question
to lkml and we would be interested to know how x86_64 solves this
problem.

Thanks.

Jun

----------------------------------------------------------------------
Hi all,
I stuck in simple situation:
USB mouse (or keyboard). n64 kernel (2.4.20), n32 userland.

Userspace application tries to read "input_event" (16 bytes) from
"/dev/input/event0" [ read(fd,&key_ev, sizeof(key_ev)) ],
input core driver treats "input_event" as 24 bytes structure. It is due
to different size of "timeval" (and finally "long") in n64 kernel and
n32 userland.

Application gets some garbage as mouse events . No solutions like "ioctl
wrappers" applicable in this case.

I don't want to change any arch independent files, but can not find any
acceptable solution. It looks like headers "/usr/include/linux/input.h"
in root file system and "/include/linux/input.h" in kernel should be the
same,
(All works fine as soon as I declare a new "input_event" structure in
user application that corresponds in size to kernel
structure - but this is not acceptable).

Can anybody advice me what to do with the difference in "input_event"
structure sizes in o32/n32 userland and n64 kernel? Just a general
approach that can be used when driver's read/write operation treat some
values as 64 bit while user application tries to read/write 32-bit
values (based on the same headers).

Please, don't kick me if solution is simple and obvious.

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2005-03-22 14:03    [W:0.036 / U:0.148 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site