On Sat, May 19, 2012 at 4:47 PM, H. Peter Anvin <hpa@xxxxxxxxx> wrote: > On 05/18/2012 02:21 PM, Arnd Bergmann wrote: >> On Friday 18 May 2012, H.J. Lu wrote: >>> Since x32 uses the same kernel interface as x86-64 with a few >>> exceptions. The current kernel header files with >>> >>> #ifdef __x86_64__ >>> # define __BITS_PER_LONG 64 >>> #else >>> # define __BITS_PER_LONG 32 >>> #endif >>> >>> #if __BITS_PER_LONG == 64 >>> Define x86-64 types >>> #endif >>> >>> work fine for x32 even if long for x32 is 32 bits. If __BITS_PER_LONG >>> is changed to 32 for x32, many types in kernel header files will be >>> wrong for x32. >>> >> >> A lot of things are broken if __BITS_PER_LONG is set to 64 in x32 user >> space. It was specifically introduced to get around places in exported >> headers that incorrectly used '#ifdef CONFIG_64BIT' to define a user >> space structure, so that we can depend on whatever the user sees >> in bitmasks and other data structures. >> > > I'm not entirely sure I follow the above statement, as it seems > contradict itself. Either way, I would agree, __BITS_PER_LONG should be > 32 in x32 space and if there are places where that is wrong then we need > to fix them. > > Fortunately x32 is littleendian, so no "littleendian bitmask on a > bigendian architecture" drain bamage... > If __BITS_PER_LONG is set to 32 for x32, we need to audit all exported kernel headers where __BITS_PER_LONG is checked. If long is used in those places, it has to be updated for x32. -- H.J. -- 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
