![]() | |||||||||||
Messages in this thread |
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/ | ||||||||||
| Last update: 2005-03-22 14:08 [from the cache] ©2003-2008 | |||||||||||