Re: [PATCH 08/10] Use __kernel_ulong_t in struct msqid64_ds

[Arnd Bergmann <arnd@arndb.de>]

On Friday 18 May 2012, Linus Torvalds wrote:
> For example, instead of this horrible crap:
> 
>           __kernel_time_t msg_stime;      /* last msgsnd time */
>   #if __BITS_PER_LONG != 64
>           unsigned long   __unused1;
>   #endif
> 
> which is just nasty, we could have something much cleaner like this:
> 
>   #define align_64_entry(type,name) \
>               union { type name; __u64 __align_##name; }
> 
> and then just use
> 
>            align_64_entry(__kernel_time_t msg_stime);
> 
> without any preprocessor #if/#ifdef crap anywhere.
> 
> It would keep the current state for the (apparently broken) case of
> 64-bit kernel and 32-bit user space with big-endian architectures, but
> it would also just magically work if __kernel_time_t is 64-bit
> despite "long" being 32-bit.
> 
> So it would fix the x32 case, as far as I can tell.
> 
> Note: totally untested. Maybe there's some reason why my anonymous
> union trick wouldn't work.

When the header files were written, we still allowed them to be included
by programs that were written for older non-gcc compilers.

We already rely on 'long long' being a valid type these days, so we could
probably extend the requirement to cover anonymous unions as well, but
there may be cases where some code includes this file and needs to get
built with -std=something-old that doesn't allow anonymous unions.

As another historical background on this header, note that some big-endian
architectures put the padding before the variable but others don't,
presumably because the person doing the architecture port didn't understand
the intention or didn't care.

However, in the kernel we *always* copy the fields one by one for compat
mode, even for the architectures that have identical layout between 32 and
64 bit, and at least one libc implementation that I've seen (IIRC uClibc)
hardcodes the data structure to be the same as x86, with the padding
after the 'long', for all architectures. When I introduced the asm-generic
version of this, we had a discussion about whether we should try to use
the version with the "correct" padding but in the end decided to just use
the x86 version because that is what most big-endian architectures do
anyway.

	Arnd