Bug 63643 - Missing begin comment in /usr/include/asm/atomic.h
Summary: Missing begin comment in /usr/include/asm/atomic.h
Keywords:
Status: CLOSED RAWHIDE
Alias: None
Product: Red Hat Public Beta
Classification: Retired
Component: glibc-kernheaders
Version: skipjack-beta2
Hardware: i386
OS: Linux
medium
medium
Target Milestone: ---
Assignee: Arjan van de Ven
QA Contact: Brian Brock
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2002-04-16 18:15 UTC by Blair Zajac
Modified: 2007-04-18 16:42 UTC (History)
3 users (show)

Fixed In Version:
Clone Of:
Environment:
Last Closed: 2002-04-16 18:15:35 UTC
Embargoed:


Attachments (Terms of Use)

Description Blair Zajac 2002-04-16 18:15:30 UTC
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:

Comment 1 Arjan van de Ven 2002-04-16 18:36:33 UTC
Yup, fixed already.
However nothing should ever include atomic.h though.....

Comment 2 Blair Zajac 2002-04-16 18:44:49 UTC
The Apache Portable Runtime (http://apr.apache.org) explicitly includes
this file in include/apr_atomic.h.

Best,
Blair


Comment 3 Arjan van de Ven 2002-04-16 20:19:58 UTC
Yuck


APR is broken. Very broken. It makes assumptions that are just not true.....

Comment 4 Ian Holsman 2002-04-29 05:26:05 UTC
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 07:14:56 UTC
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


Comment 6 Justin Erenkrantz 2002-04-29 22:12:19 UTC
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 04:55:44 UTC
jerenkrantz: 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.