On Mon, Sep 19, 2011 at 2:15 AM, Arnd Bergmann <a...@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 > _______________________________________________ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
