ioctl ABI considerations for 64b ARM?

[Rob Clark]

On Mon, Sep 19, 2011 at 2:15 AM, Arnd Bergmann <arnd at arndb.de> wrote:
> On Sunday 18 September 2011 15:24:37 Rob Clark wrote:
>> I don't suppose there are any guidelines from ARM about compatibility
>> between 32bit userspace and 64bit kernel on some hypothetical future
>> version of the ARM architecture?  Some hints about what to do or not
>> do could perhaps save some ioctl compat glue later on down the line..
>
> There are some rules that should be followed regardless:
>
> * ioctl commands should never be written in an architecture specific
>  way. In the example of the OMAP driver, you definitely want to be
>  able ot use the same command when running Linux on the C6x DSP.
>
> * If possible, use only scalar values as ioctl arguments
>
> * Avoid types that are register sized: 'long', 'size_t', pointer.
>  Instead use only __u8, __u16, __u32 and __u64 and their signed
>  versions.

ok..  I'm using stdint types (ie. uint8_t, etc..)  so same result

> * If you use structures, try very hard to avoid pointers in them,
>  it messes up all sorts of tools.
>
> * If you use structures, make all members naturally aligned, and pad
>  the size of the structures to a multiple of the maximum member size.
>
> * Never put sub-command numbers into a structure.

I didn't get this comment.. what is special about sub-command #'s?

BR,
-R

>> > But since there is no 64-bit ARM yet, it might be better to rely on using
>> > compat code in the future than on making guesses about alignment
>> > restrictions of the ABI...
>>
>> hmm, it might be nice to get some guidelines from ARM on this, since I
>> really have no idea what a 64b ARM architecture would look like...
>
> Assuming that we can prevent any funny stuff from going into such an ABI,
> we only need to worry about the warts of the current ABI for ARM specific
> considerations. The one thing that I've noticed before is that structs
> on ARM (at least on one of the ABIs, forgot which) are padded to 32 bits,
> even if all members inside are smaller.
>
> It would be a huge pain if a 64 bit ABI had /different/ padding rules
> here, like not padding (logical choice by itself, but hurts is here),
> or padding everything to 64 bits (maybe not worth porting the kernel to
> then).
>
>        Arnd
>