On Thu, May 17, 2012 at 9:05 PM, Linus Torvalds <torvalds@xxxxxxxxxxxxxxxxxxxx> wrote: > On Thu, May 17, 2012 at 8:59 PM, H.J. Lu <hjl.tools@xxxxxxxxx> wrote: >> >> But __BITS_PER_LONG used in kernel header files really >> means "long" as seen by kernel, not by user space. > > No, hjl, no it does NOT. > > That might be what we'd all *wish* it did, but it's not at all what it does. > > What it actually means is "how many bits in a long as it is being > compiled right now". > > User code headers have absolutely *no* idea what the size "long" the > kernel was compiled with. You'd have to do an "uname()" system call to > figure that out, and even then you shouldn't be sure if the kernel is > just really good at compatibility mode. > > Just look at the code. It literally sets __BITS_PER_LONG depending on > *compiler* flags like __s390x__ etc. Which depend on things like > "-m32" etc as done in user space. > > When those same headers are compiled *as*part*of*the*kernel*, then - > and only then - does __BITS_PER_LONG hopefully match what the kernel > "long" is. But that is kind of irrelevant, because if this was purely > a kernel issue, we would use the non-underscore version (ie just > "BITS_PER_LONG") which is *only* for the kernel, and not exported to > user space at all. > 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. -- 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
