While debugging some force-feedback issues ran into an interesting problem. The size of one struct from include/linux differs between 32-bit and 64-bit. That wouldn't be a major problem except that size is the part of the ioctl() request. Which results in EINVAL.
In more details: input.h: #define EVIOCSFF _IOC(_IOC_WRITE, 'E', 0x80, sizeof(struct ff_effect))
The simple test program:
#include <linux/input.h> #include <stdio.h> int main(int argc, char * argv[]) { printf("sizeof(struct ff_effect) = %d EVIOCSFF=%#x\n", sizeof(struct ff_effect), EVIOCSFF);
return 0; }
$ gcc test_size.c -o test_size && ./test_size sizeof(struct ff_effect) = 48 EVIOCSFF=0x40304580 $ gcc -m32 test_size.c -o test_size32 && ./test_size32 sizeof(struct ff_effect) = 44 EVIOCSFF=0x402c4580
The question is what do we do about it? I'm sure there are might be more cases like that.
Vitaliy
2008/8/13 Vitaliy Margolen wine-devel@kievinfo.com:
While debugging some force-feedback issues ran into an interesting problem. The size of one struct from include/linux differs between 32-bit and 64-bit. That wouldn't be a major problem except that size is the part of the ioctl() request. Which results in EINVAL.
Maybe I misunderstand the issue, but doesn't Wine currently always get compiled for 32-bit? (Iow, we always get the 32-bit version of the structure)
Am Mittwoch, den 13.08.2008, 09:07 +0200 schrieb H. Verbeet:
Maybe I misunderstand the issue, but doesn't Wine currently always get compiled for 32-bit? (Iow, we always get the 32-bit version of the structure)
Yes, but if wine runs on a 64 bit kernel, the kernel does not handle the request, as it only recognizes the 64 bit request, if I understood Vitaliy correct. I consider that a kernel bug.
Regards, Michael Karcher
2008/8/13 Michael Karcher wine@mkarcher.dialup.fu-berlin.de:
Yes, but if wine runs on a 64 bit kernel, the kernel does not handle the request, as it only recognizes the 64 bit request, if I understood Vitaliy correct. I consider that a kernel bug.
I'd say so, yeah.
"Vitaliy Margolen" wine-devel@kievinfo.com wrote:
While debugging some force-feedback issues ran into an interesting problem. The size of one struct from include/linux differs between 32-bit and 64-bit. That wouldn't be a major problem except that size is the part of the ioctl() request. Which results in EINVAL.
64-bit kernel should take care of translating the parameters between native 64-bit and emulated 32-bit modes. If that's not the case that's a kernel bug, and should be reported appropriately.
On Tue, Aug 12, 2008 at 11:44:20PM -0600, Vitaliy Margolen wrote:
While debugging some force-feedback issues ran into an interesting problem. The size of one struct from include/linux differs between 32-bit and 64-bit. That wouldn't be a major problem except that size is the part of the ioctl() request. Which results in EINVAL.
In more details: input.h: #define EVIOCSFF _IOC(_IOC_WRITE, 'E', 0x80, sizeof(struct ff_effect))
The simple test program:
#include <linux/input.h> #include <stdio.h> int main(int argc, char * argv[]) { printf("sizeof(struct ff_effect) = %d EVIOCSFF=%#x\n", sizeof(struct ff_effect), EVIOCSFF);
return 0;
}
$ gcc test_size.c -o test_size && ./test_size sizeof(struct ff_effect) = 48 EVIOCSFF=0x40304580 $ gcc -m32 test_size.c -o test_size32 && ./test_size32 sizeof(struct ff_effect) = 44 EVIOCSFF=0x402c4580
The question is what do we do about it? I'm sure there are might be more cases like that.
The kernel is supposed to handle this transparently.
I would report this to the kernel developers, mention "32bit compatibility" or so.
Ciao, Marcus
Marcus Meissner wrote:
On Tue, Aug 12, 2008 at 11:44:20PM -0600, Vitaliy Margolen wrote:
While debugging some force-feedback issues ran into an interesting problem. The size of one struct from include/linux differs between 32-bit and 64-bit. That wouldn't be a major problem except that size is the part of the ioctl() request. Which results in EINVAL.
In more details: input.h: #define EVIOCSFF _IOC(_IOC_WRITE, 'E', 0x80, sizeof(struct ff_effect))
The simple test program:
#include <linux/input.h> #include <stdio.h> int main(int argc, char * argv[]) { printf("sizeof(struct ff_effect) = %d EVIOCSFF=%#x\n", sizeof(struct ff_effect), EVIOCSFF);
return 0;
}
$ gcc test_size.c -o test_size && ./test_size sizeof(struct ff_effect) = 48 EVIOCSFF=0x40304580 $ gcc -m32 test_size.c -o test_size32 && ./test_size32 sizeof(struct ff_effect) = 44 EVIOCSFF=0x402c4580
The question is what do we do about it? I'm sure there are might be more cases like that.
The kernel is supposed to handle this transparently.
I would report this to the kernel developers, mention "32bit compatibility" or so.
Just for the record, it has been fixed for 2.6.27: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdif...