Messages in this thread | | | Date | Mon, 29 Nov 2004 20:53:19 +1100 | From | Paul Mackerras <> | Subject | Re: [RFC] Splitting kernel headers and deprecating __KERNEL__ |
| |
Linus Torvalds writes:
> In particular, any re-organization that breaks _existing_ uses is totally > pointless. If you break existing uses, you might as well _not_ re- > organize, since if you consider kernel headers to be purely kernel- > internal (like they should be, but hey, reality trumps any wishes we might > have), then the current organization is perfectly fine.
Recently I had some users complaining because their userspace program that includes <asm/atomic.h> compiles OK as a ppc64 program but not as a ppc32 program. The reason for that is that asm-ppc/atomic.h has #ifdef __KERNEL__ around the inline definitions of atomic_inc et al., but asm-ppc64/atomic.h doesn't.
My response was that they shouldn't be using <asm/atomic.h> because (a) it's an internal kernel header, not part of the kernel ABI, (b) it's not portable (it happens to work on some popular architectures, but won't work on all) and (c) they're really only entitled to use those particular inline function definitions in GPL'd programs anyway.
To which the obvious reply is "well then why is it in /usr/include?" It's because the glibc build process copies all the kernel headers to /usr/include, but that's not an answer from a user's point of view.
I'd be interested to hear your take on this. Should we try to make our atomics easy and safe for userspace to use (including putting them under the LGPL)? Or can you see a better solution?
Paul. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |