What to do when size of the struct differs on 32 and 64 bit?

[Vitaliy Margolen]

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

[H. Verbeet]

2008/8/13 Vitaliy Margolen <wine-devel(a)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)

[Michael Karcher]

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

[H. Verbeet]

2008/8/13 Michael Karcher <wine(a)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.

[Dmitry Timoshkov]

"Vitaliy Margolen" <wine-devel(a)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.

-- 
Dmitry.

[Marcus Meissner]

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

[Anssi Hannula]

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...

-- 
Anssi Hannula