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.
Linus
--
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
