Re: [RFC] Splitting kernel headers and deprecating __KERNEL__

[Paul Mackerras]

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@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/