Bug 63643 - Missing begin comment in /usr/include/asm/atomic.h
Missing begin comment in /usr/include/asm/atomic.h
Product: Red Hat Public Beta
Classification: Retired
Component: glibc-kernheaders (Show other bugs)
i386 Linux
medium Severity medium
: ---
: ---
Assigned To: Arjan van de Ven
Brian Brock
Depends On:
  Show dependency treegraph
Reported: 2002-04-16 14:15 EDT by Blair Zajac
Modified: 2007-04-18 12:42 EDT (History)
3 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2002-04-16 14:15:35 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Blair Zajac 2002-04-16 14:15:30 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:

Steps to Reproduce:
1. Examine /usr/include/asm/atomic.h

Additional info:
Comment 1 Arjan van de Ven 2002-04-16 14:36:33 EDT
Yup, fixed already.
However nothing should ever include atomic.h though.....
Comment 2 Blair Zajac 2002-04-16 14:44:49 EDT
The Apache Portable Runtime (http://apr.apache.org) explicitly includes
this file in include/apr_atomic.h.

Comment 3 Arjan van de Ven 2002-04-16 16:19:58 EDT

APR is broken. Very broken. It makes assumptions that are just not true.....
Comment 4 Ian Holsman 2002-04-29 01:26:05 EDT
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#)
Comment 5 Arjan van de Ven 2002-04-29 03:14:56 EDT
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
   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
Comment 6 Justin Erenkrantz 2002-04-29 18:12:19 EDT
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.
Comment 7 Arjan van de Ven 2002-04-30 00:55:44 EDT
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....

Note You need to log in before you can comment on or make changes to this bug.