ioctl ABI considerations for 64b ARM?
rob.clark at linaro.org
Mon Sep 19 14:37:12 UTC 2011
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
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?
>> > 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
More information about the linaro-dev