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