Red Hat Bugzilla – Bug 63643
Missing begin comment in /usr/include/asm/atomic.h
Last modified: 2007-04-18 12:42:03 EDT
From Bugzilla Helper: User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.0; Q312461; .NET CLR 1.0.3705) Description of problem: In glibc-kernheaders-2.4-7.13 the file /usr/include/asm/atomic.h at line 11 is missing a begin comment at "Make sure", so compiles fail when including this file: #ifndef __ARCH_I386_ATOMIC__ #define __ARCH_I386_ATOMIC__ #include <linux/config.h> /* * Atomic operations that C can't guarantee us. Useful for * resource counting etc.. */ * Make sure gcc doesn't try to be clever and move things around * on us. We need to use _exactly_ the address the user gave us, * not some alias that contains the same information. */ Version-Release number of selected component (if applicable): How reproducible: Always Steps to Reproduce: 1. Examine /usr/include/asm/atomic.h 2. 3. Additional info:
Yup, fixed already. However nothing should ever include atomic.h though.....
The Apache Portable Runtime (http://apr.apache.org) explicitly includes this file in include/apr_atomic.h. Best, Blair
Yuck APR is broken. Very broken. It makes assumptions that are just not true.....
what assumptions does it make? it looks like the current 'standard' kernel version of atomic.h is different to redhat's ('beta') version is there a actual reason for this (bug#)
1) it makes the assumption that those functions are also atomic in userspace, which isn't the case actually (not even on i386) 2) it makes the assumption that those functions compile in userspace, which isn't the case all architectures (some architectures need to use spinlocks for this since the cpu doesn't have the atomic ops themselves) 3) this is not a kernel header. It's a glibc header which happens to be derived from the kernel. There reasons for the header to be different: 1) it doesn't do what people think it does resulting in nasty bugs (see #1 above). Our developer support department had several nasty cases with this. 2) it's a kernel private header. there's NO guarantee about this not breaking for different kernel versions. The glibc headers package however is there to provide a stable API for userspace. This means that internal, not-for-userspace headers (or parts of headers) cannot be in that since the kernel developers don't guarantee API stability in those, not even in a stable kernel series. (and esp not for userspace use) 3) There's the angle that these inlines are covered by the GPL license. Programs using them would therefor include compiled gpl code in their binary, which is a legal minefield at best
Our biggest concern is that Linux doesn't have any userspace atomic interface (such as FreeBSD-CURRENT does). I have submitted a patch to the APR development list to use handcoded assembly (based on FreeBSD's assembly code since APR can't touch the Linux source code), but I really feel that this is something that the core OS should be handling.
jerenkrantz@apache.org: I agree, however that would be a glibc task, not a kernel one; you don't want a syscall for every atomic operation....