Messages in this thread | | | Subject | Re: [RFC] Splitting kernel headers and deprecating __KERNEL__ | From | Arjan van de Ven <> | Date | Mon, 29 Nov 2004 10:57:12 +0100 |
| |
On Mon, 2004-11-29 at 20:53 +1100, Paul Mackerras wrote: > 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.
and (d) on x86 at least the "atomic" part of the atomic ops are #ifdef CONFIG_SMP, which might well not be set in userland... so you get a false sense of atomicity.
> 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?
it's not the kernel's job to provide this functionality imo. glibc could. glib does. apr does. there's several options already. apr is BSD licensed for exanpmle, glib LGPL.
- 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/
| |