On Friday 18 May 2012, H. Peter Anvin wrote: > > On 05/18/2012 02:31 PM, Arnd Bergmann wrote: > > > > 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. > > > > Ouch. Fail. asm-generic should be about what is the right thing going > forward. But why do you think it's wrong the way it is? I see the idea of putting padding in varying places depending on the endianess as a failed experiment and defining a structure that is always the same as the logical conclusion from that, even if it's a bit silly to have any padding in it at all. Being consistent seems more important here than following the intent of whoever came up with the concept of the ipc64 data structures and was consequently ignored by most people after him. If we really wanted the data structures to be compatible between 32 and 64 bit mode, we'd have to use __u64 here but that would mean having to change all bits of user code that already rely on the existing x86 compatible layout. Arnd -- To unsubscribe from this list: send the line "unsubscribe linux-arch" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
