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

Re: INPUT_COMPAT_TEST

From: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Date: 2011-09-07 18:37:51

On Wed, Sep 07, 2011 at 11:22:10AM -0700, H. Peter Anvin wrote:
On 09/07/2011 11:16 AM, Dmitry Torokhov wrote:
quoted
On Sat, Jul 09, 2011 at 01:04:53AM -0700, H. Peter Anvin wrote:
quoted
On 07/08/2011 05:35 PM, Dmitry Torokhov wrote:
quoted
Input only need to do this compat stuff on read/write paths so maybe if
you add plumbing similar to compat_ioctl we could switch owver to it.
The problem is that read/write ties into a large number of system calls,
and input is the *only* subsystem which needs it.
BTW, while listening to x32 resentation on LPC I realized that the need
for compat tests on read/write paths in input subsystem is due to use of
timeval in input_event structures. If x32 solved the time_t issue by
moving to 64 bit times then input read/write should simply use native
64 bit operations.

That still leaves sysfs and proc business of course...
I thought there were pointers, (or longs) there too.

In fact, we might have had the worst of both worlds here...
The pointers are in ioctl paths (upload of force-feedback effects with
custom waveforms - noone actually uses them in real life).

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