[PATCH] Export PowerPC atomic operations to userspace

[PATCH] Export PowerPC atomic operations to userspace

[Brent Cook]

The atomic operations in asm/atomic.h are really useful from userspace too. 
Other architectures (i386, x86_64, mips) export these to userspace, but the 
powerpc versions are guarded by __KERNEL__ for some reason. Can we remove 
these if there is no good reason to guard them?

Signed-off-by: Brent Cook <bcook@bpointsys.com>

Index: linux-2.6-bps/include/asm-powerpc/atomic.h
===================================================================
--- linux-2.6-bps/include/asm-powerpc/atomic.h  (revision 77)
+++ linux-2.6-bps/include/asm-powerpc/atomic.h  (working copy)
@@ -7,7 +7,6 @@

 typedef struct { volatile int counter; } atomic_t;

-#ifdef __KERNEL__
 #include <linux/compiler.h>
 #include <asm/synch.h>
 #include <asm/asm-compat.h>
@@ -414,5 +413,4 @@
 #endif /* __powerpc64__ */

 #include <asm-generic/atomic.h>
-#endif /* __KERNEL__ */
 #endif /* _ASM_POWERPC_ATOMIC_H_ */

Re: [PATCH] Export PowerPC atomic operations to userspace

[Tom Rini]

On Mon, May 15, 2006 at 11:54:52AM -0500, Brent Cook wrote:

> The atomic operations in asm/atomic.h are really useful from userspace too. 
> Other architectures (i386, x86_64, mips) export these to userspace, but the 
> powerpc versions are guarded by __KERNEL__ for some reason. Can we remove 
> these if there is no good reason to guard them?
> 
> Signed-off-by: Brent Cook <bcook@bpointsys.com>

NAK.  i386, x86_64 and mips are broken in this regard.  Please google up
the previous threads that explain why you can't always get atomic
operations on all architectures and why exporting this is bad.

-- 
Tom Rini

Re: [PATCH] Export PowerPC atomic operations to userspace

[Brent Cook]

On Monday 15 May 2006 12:16, Tom Rini wrote:
> On Mon, May 15, 2006 at 11:54:52AM -0500, Brent Cook wrote:
> > The atomic operations in asm/atomic.h are really useful from userspace
> > too. Other architectures (i386, x86_64, mips) export these to userspace,
> > but the powerpc versions are guarded by __KERNEL__ for some reason. Can
> > we remove these if there is no good reason to guard them?
> >
> > Signed-off-by: Brent Cook <bcook@bpointsys.com>
>
> NAK.  i386, x86_64 and mips are broken in this regard.  Please google up
> the previous threads that explain why you can't always get atomic
> operations on all architectures and why exporting this is bad.

OK, I see that possibly the only reason atomic_t is even exported is so that 
sem.h works. Hopefully sem.h will get fixed and people like me will not be 
even tempted by atomic.h.

What I really want is just a standard way to do atomic inc/dec in userspace; 
I'm sure that people are going to continue wanting to have atomic_t 
workalikes for their code.

After reading this thread: 
http://www.developerweb.net/forum/archive/index.php/t-3294.html
it appears that just wrapping an integer in a pthreads mutex on an NPTL 
machine wouldn't be much more overhead than using an atomic_t directly.

Looking at glibc's sources for powerpc nptl:

nptl/sysdeps/unix/sysv/linux/powerpc/lowlevellock.h

confirms that a futex lock is really similar to an atomic_t.

Thanks!

 - Brent