Re: [Xenomai-core] [3/9] Define more atomic operations in user-space
Gilles Chanteperdrix wrote: Philippe Gerum wrote: Gilles Chanteperdrix wrote: On Fri, Apr 25, 2008 at 4:01 PM, Philippe Gerum [EMAIL PROTECTED] wrote: Gilles Chanteperdrix wrote: On Fri, Apr 25, 2008 at 3:42 PM, Philippe Gerum [EMAIL PROTECTED] wrote: Gilles Chanteperdrix wrote: On Fri, Apr 25, 2008 at 9:48 AM, Philippe Gerum [EMAIL PROTECTED] wrote: Gilles Chanteperdrix wrote: This patch implements the _read, _set, and _cmpxchg operations on atomic_long_t and atomic_ptr_t in user-space in include/asm-generic/atomic.h which should be included at the end of include/asm-*/atomic.h after the definition of the same operations for the atomic_t type and atomic64_t type on 64 bits platforms. These operations are the basic operations used by user-space mutexes. Maybe we should add the xnarch_ prefix ? Yes, but more generally, we should rework this to fit the existing atomic support in include/asm-*/atomic.h, so that we don't end up with sideways to what has been already designed to support set, get, xchg and the like, in both kernel and userland context. That is not exactly sideways... Linux include/asm-generic/atomic.h defines operations for atomic_long_t. This file adds two things: - support for atomic_long_t in user-space (where we can not include linux include/asm-generic/atomic.h) - support for a new type atomic_ptr_t both to kernel-space and user-space, the aim is to avoid all the casts that would take place if we wanted to use atomic_long_t to store pointers. However for this file to work, it has to be included by asm-*/atomic.h after the definition of atomic_t (and atomic64_t on 64 bits platforms). So linux includes asm-generic/atomic.h at the end of asm/atomic.h, I simply reproduced this scheme with Xenomai include/asm-*/atomic.h. Focusing on user-space: 1) xnarch_atomic_xchg is meant to work on long types; 2) set, get routines are not defined in that scope. If the purpose is to define integer-type ops to handle pointer-type data atomically (i.e. intptr_t), then I would rather check whether we actually need non-long support at all in user-space. In case we don't, I would simply reply on the existing implementation of asm-*/atomic.h + the set / get extensions you provide. I use both atomic_t and atomic_ptr_t for the implementation of user-space mutexes. The problem is that I am constrained by the size of pthread_mutex_t, so the control block read-write locks implementation use atomic_t. Ok, makes sense. Let's just fix the namespace then, so that we don't get the feeling of having duplicate sets of operations. That said, there is just enough room for replacing the atomic_t with an atomic_long_t. So, we can make xnarch_atomic_t a long type. Have you anything agains making an xnarch_atomic_ptr_t ? No objection, just let us call it xnarch_atomic_intptr_t to ANSIfy this a bit more, and clearly state that we need this type to hold a pointer into an integer value, and operate atomically on it. Ok. The current type defined in asm-arm/atomic.h is atomic_counter_t. Should I rename this xnarch_atomic_t ? Fine with me. I ask this now, because I am going to do search and replaces of atomic_ all over my changes, so, I prefer to know before. -- Philippe. ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] [3/9] Define more atomic operations in user-space
On Fri, Apr 25, 2008 at 9:48 AM, Philippe Gerum [EMAIL PROTECTED] wrote: Gilles Chanteperdrix wrote: This patch implements the _read, _set, and _cmpxchg operations on atomic_long_t and atomic_ptr_t in user-space in include/asm-generic/atomic.h which should be included at the end of include/asm-*/atomic.h after the definition of the same operations for the atomic_t type and atomic64_t type on 64 bits platforms. These operations are the basic operations used by user-space mutexes. Maybe we should add the xnarch_ prefix ? Yes, but more generally, we should rework this to fit the existing atomic support in include/asm-*/atomic.h, so that we don't end up with sideways to what has been already designed to support set, get, xchg and the like, in both kernel and userland context. That is not exactly sideways... Linux include/asm-generic/atomic.h defines operations for atomic_long_t. This file adds two things: - support for atomic_long_t in user-space (where we can not include linux include/asm-generic/atomic.h) - support for a new type atomic_ptr_t both to kernel-space and user-space, the aim is to avoid all the casts that would take place if we wanted to use atomic_long_t to store pointers. However for this file to work, it has to be included by asm-*/atomic.h after the definition of atomic_t (and atomic64_t on 64 bits platforms). So linux includes asm-generic/atomic.h at the end of asm/atomic.h, I simply reproduced this scheme with Xenomai include/asm-*/atomic.h. -- Gilles ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] [3/9] Define more atomic operations in user-space
Gilles Chanteperdrix wrote: On Fri, Apr 25, 2008 at 9:48 AM, Philippe Gerum [EMAIL PROTECTED] wrote: Gilles Chanteperdrix wrote: This patch implements the _read, _set, and _cmpxchg operations on atomic_long_t and atomic_ptr_t in user-space in include/asm-generic/atomic.h which should be included at the end of include/asm-*/atomic.h after the definition of the same operations for the atomic_t type and atomic64_t type on 64 bits platforms. These operations are the basic operations used by user-space mutexes. Maybe we should add the xnarch_ prefix ? Yes, but more generally, we should rework this to fit the existing atomic support in include/asm-*/atomic.h, so that we don't end up with sideways to what has been already designed to support set, get, xchg and the like, in both kernel and userland context. That is not exactly sideways... Linux include/asm-generic/atomic.h defines operations for atomic_long_t. This file adds two things: - support for atomic_long_t in user-space (where we can not include linux include/asm-generic/atomic.h) - support for a new type atomic_ptr_t both to kernel-space and user-space, the aim is to avoid all the casts that would take place if we wanted to use atomic_long_t to store pointers. However for this file to work, it has to be included by asm-*/atomic.h after the definition of atomic_t (and atomic64_t on 64 bits platforms). So linux includes asm-generic/atomic.h at the end of asm/atomic.h, I simply reproduced this scheme with Xenomai include/asm-*/atomic.h. Focusing on user-space: 1) xnarch_atomic_xchg is meant to work on long types; 2) set, get routines are not defined in that scope. If the purpose is to define integer-type ops to handle pointer-type data atomically (i.e. intptr_t), then I would rather check whether we actually need non-long support at all in user-space. In case we don't, I would simply reply on the existing implementation of asm-*/atomic.h + the set / get extensions you provide. -- Philippe. ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] [3/9] Define more atomic operations in user-space
On Fri, Apr 25, 2008 at 3:42 PM, Philippe Gerum [EMAIL PROTECTED] wrote: Gilles Chanteperdrix wrote: On Fri, Apr 25, 2008 at 9:48 AM, Philippe Gerum [EMAIL PROTECTED] wrote: Gilles Chanteperdrix wrote: This patch implements the _read, _set, and _cmpxchg operations on atomic_long_t and atomic_ptr_t in user-space in include/asm-generic/atomic.h which should be included at the end of include/asm-*/atomic.h after the definition of the same operations for the atomic_t type and atomic64_t type on 64 bits platforms. These operations are the basic operations used by user-space mutexes. Maybe we should add the xnarch_ prefix ? Yes, but more generally, we should rework this to fit the existing atomic support in include/asm-*/atomic.h, so that we don't end up with sideways to what has been already designed to support set, get, xchg and the like, in both kernel and userland context. That is not exactly sideways... Linux include/asm-generic/atomic.h defines operations for atomic_long_t. This file adds two things: - support for atomic_long_t in user-space (where we can not include linux include/asm-generic/atomic.h) - support for a new type atomic_ptr_t both to kernel-space and user-space, the aim is to avoid all the casts that would take place if we wanted to use atomic_long_t to store pointers. However for this file to work, it has to be included by asm-*/atomic.h after the definition of atomic_t (and atomic64_t on 64 bits platforms). So linux includes asm-generic/atomic.h at the end of asm/atomic.h, I simply reproduced this scheme with Xenomai include/asm-*/atomic.h. Focusing on user-space: 1) xnarch_atomic_xchg is meant to work on long types; 2) set, get routines are not defined in that scope. If the purpose is to define integer-type ops to handle pointer-type data atomically (i.e. intptr_t), then I would rather check whether we actually need non-long support at all in user-space. In case we don't, I would simply reply on the existing implementation of asm-*/atomic.h + the set / get extensions you provide. I use both atomic_t and atomic_ptr_t for the implementation of user-space mutexes. The problem is that I am constrained by the size of pthread_mutex_t, so the control block read-write locks implementation use atomic_t. -- Gilles ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] [3/9] Define more atomic operations in user-space
Gilles Chanteperdrix wrote: On Fri, Apr 25, 2008 at 3:42 PM, Philippe Gerum [EMAIL PROTECTED] wrote: Gilles Chanteperdrix wrote: On Fri, Apr 25, 2008 at 9:48 AM, Philippe Gerum [EMAIL PROTECTED] wrote: Gilles Chanteperdrix wrote: This patch implements the _read, _set, and _cmpxchg operations on atomic_long_t and atomic_ptr_t in user-space in include/asm-generic/atomic.h which should be included at the end of include/asm-*/atomic.h after the definition of the same operations for the atomic_t type and atomic64_t type on 64 bits platforms. These operations are the basic operations used by user-space mutexes. Maybe we should add the xnarch_ prefix ? Yes, but more generally, we should rework this to fit the existing atomic support in include/asm-*/atomic.h, so that we don't end up with sideways to what has been already designed to support set, get, xchg and the like, in both kernel and userland context. That is not exactly sideways... Linux include/asm-generic/atomic.h defines operations for atomic_long_t. This file adds two things: - support for atomic_long_t in user-space (where we can not include linux include/asm-generic/atomic.h) - support for a new type atomic_ptr_t both to kernel-space and user-space, the aim is to avoid all the casts that would take place if we wanted to use atomic_long_t to store pointers. However for this file to work, it has to be included by asm-*/atomic.h after the definition of atomic_t (and atomic64_t on 64 bits platforms). So linux includes asm-generic/atomic.h at the end of asm/atomic.h, I simply reproduced this scheme with Xenomai include/asm-*/atomic.h. Focusing on user-space: 1) xnarch_atomic_xchg is meant to work on long types; 2) set, get routines are not defined in that scope. If the purpose is to define integer-type ops to handle pointer-type data atomically (i.e. intptr_t), then I would rather check whether we actually need non-long support at all in user-space. In case we don't, I would simply reply on the existing implementation of asm-*/atomic.h + the set / get extensions you provide. I use both atomic_t and atomic_ptr_t for the implementation of user-space mutexes. The problem is that I am constrained by the size of pthread_mutex_t, so the control block read-write locks implementation use atomic_t. Ok, makes sense. Let's just fix the namespace then, so that we don't get the feeling of having duplicate sets of operations. -- Philippe. ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] [3/9] Define more atomic operations in user-space
On Fri, Apr 25, 2008 at 4:01 PM, Philippe Gerum [EMAIL PROTECTED] wrote: Gilles Chanteperdrix wrote: On Fri, Apr 25, 2008 at 3:42 PM, Philippe Gerum [EMAIL PROTECTED] wrote: Gilles Chanteperdrix wrote: On Fri, Apr 25, 2008 at 9:48 AM, Philippe Gerum [EMAIL PROTECTED] wrote: Gilles Chanteperdrix wrote: This patch implements the _read, _set, and _cmpxchg operations on atomic_long_t and atomic_ptr_t in user-space in include/asm-generic/atomic.h which should be included at the end of include/asm-*/atomic.h after the definition of the same operations for the atomic_t type and atomic64_t type on 64 bits platforms. These operations are the basic operations used by user-space mutexes. Maybe we should add the xnarch_ prefix ? Yes, but more generally, we should rework this to fit the existing atomic support in include/asm-*/atomic.h, so that we don't end up with sideways to what has been already designed to support set, get, xchg and the like, in both kernel and userland context. That is not exactly sideways... Linux include/asm-generic/atomic.h defines operations for atomic_long_t. This file adds two things: - support for atomic_long_t in user-space (where we can not include linux include/asm-generic/atomic.h) - support for a new type atomic_ptr_t both to kernel-space and user-space, the aim is to avoid all the casts that would take place if we wanted to use atomic_long_t to store pointers. However for this file to work, it has to be included by asm-*/atomic.h after the definition of atomic_t (and atomic64_t on 64 bits platforms). So linux includes asm-generic/atomic.h at the end of asm/atomic.h, I simply reproduced this scheme with Xenomai include/asm-*/atomic.h. Focusing on user-space: 1) xnarch_atomic_xchg is meant to work on long types; 2) set, get routines are not defined in that scope. If the purpose is to define integer-type ops to handle pointer-type data atomically (i.e. intptr_t), then I would rather check whether we actually need non-long support at all in user-space. In case we don't, I would simply reply on the existing implementation of asm-*/atomic.h + the set / get extensions you provide. I use both atomic_t and atomic_ptr_t for the implementation of user-space mutexes. The problem is that I am constrained by the size of pthread_mutex_t, so the control block read-write locks implementation use atomic_t. Ok, makes sense. Let's just fix the namespace then, so that we don't get the feeling of having duplicate sets of operations. That said, there is just enough room for replacing the atomic_t with an atomic_long_t. So, we can make xnarch_atomic_t a long type. Have you anything agains making an xnarch_atomic_ptr_t ? -- Gilles ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] [3/9] Define more atomic operations in user-space
Gilles Chanteperdrix wrote: On Fri, Apr 25, 2008 at 4:01 PM, Philippe Gerum [EMAIL PROTECTED] wrote: Gilles Chanteperdrix wrote: On Fri, Apr 25, 2008 at 3:42 PM, Philippe Gerum [EMAIL PROTECTED] wrote: Gilles Chanteperdrix wrote: On Fri, Apr 25, 2008 at 9:48 AM, Philippe Gerum [EMAIL PROTECTED] wrote: Gilles Chanteperdrix wrote: This patch implements the _read, _set, and _cmpxchg operations on atomic_long_t and atomic_ptr_t in user-space in include/asm-generic/atomic.h which should be included at the end of include/asm-*/atomic.h after the definition of the same operations for the atomic_t type and atomic64_t type on 64 bits platforms. These operations are the basic operations used by user-space mutexes. Maybe we should add the xnarch_ prefix ? Yes, but more generally, we should rework this to fit the existing atomic support in include/asm-*/atomic.h, so that we don't end up with sideways to what has been already designed to support set, get, xchg and the like, in both kernel and userland context. That is not exactly sideways... Linux include/asm-generic/atomic.h defines operations for atomic_long_t. This file adds two things: - support for atomic_long_t in user-space (where we can not include linux include/asm-generic/atomic.h) - support for a new type atomic_ptr_t both to kernel-space and user-space, the aim is to avoid all the casts that would take place if we wanted to use atomic_long_t to store pointers. However for this file to work, it has to be included by asm-*/atomic.h after the definition of atomic_t (and atomic64_t on 64 bits platforms). So linux includes asm-generic/atomic.h at the end of asm/atomic.h, I simply reproduced this scheme with Xenomai include/asm-*/atomic.h. Focusing on user-space: 1) xnarch_atomic_xchg is meant to work on long types; 2) set, get routines are not defined in that scope. If the purpose is to define integer-type ops to handle pointer-type data atomically (i.e. intptr_t), then I would rather check whether we actually need non-long support at all in user-space. In case we don't, I would simply reply on the existing implementation of asm-*/atomic.h + the set / get extensions you provide. I use both atomic_t and atomic_ptr_t for the implementation of user-space mutexes. The problem is that I am constrained by the size of pthread_mutex_t, so the control block read-write locks implementation use atomic_t. Ok, makes sense. Let's just fix the namespace then, so that we don't get the feeling of having duplicate sets of operations. That said, there is just enough room for replacing the atomic_t with an atomic_long_t. So, we can make xnarch_atomic_t a long type. Have you anything agains making an xnarch_atomic_ptr_t ? No objection, just let us call it xnarch_atomic_intptr_t to ANSIfy this a bit more, and clearly state that we need this type to hold a pointer into an integer value, and operate atomically on it. -- Philippe. ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] [3/9] Define more atomic operations in user-space
Philippe Gerum wrote: Gilles Chanteperdrix wrote: On Fri, Apr 25, 2008 at 4:01 PM, Philippe Gerum [EMAIL PROTECTED] wrote: Gilles Chanteperdrix wrote: On Fri, Apr 25, 2008 at 3:42 PM, Philippe Gerum [EMAIL PROTECTED] wrote: Gilles Chanteperdrix wrote: On Fri, Apr 25, 2008 at 9:48 AM, Philippe Gerum [EMAIL PROTECTED] wrote: Gilles Chanteperdrix wrote: This patch implements the _read, _set, and _cmpxchg operations on atomic_long_t and atomic_ptr_t in user-space in include/asm-generic/atomic.h which should be included at the end of include/asm-*/atomic.h after the definition of the same operations for the atomic_t type and atomic64_t type on 64 bits platforms. These operations are the basic operations used by user-space mutexes. Maybe we should add the xnarch_ prefix ? Yes, but more generally, we should rework this to fit the existing atomic support in include/asm-*/atomic.h, so that we don't end up with sideways to what has been already designed to support set, get, xchg and the like, in both kernel and userland context. That is not exactly sideways... Linux include/asm-generic/atomic.h defines operations for atomic_long_t. This file adds two things: - support for atomic_long_t in user-space (where we can not include linux include/asm-generic/atomic.h) - support for a new type atomic_ptr_t both to kernel-space and user-space, the aim is to avoid all the casts that would take place if we wanted to use atomic_long_t to store pointers. However for this file to work, it has to be included by asm-*/atomic.h after the definition of atomic_t (and atomic64_t on 64 bits platforms). So linux includes asm-generic/atomic.h at the end of asm/atomic.h, I simply reproduced this scheme with Xenomai include/asm-*/atomic.h. Focusing on user-space: 1) xnarch_atomic_xchg is meant to work on long types; 2) set, get routines are not defined in that scope. If the purpose is to define integer-type ops to handle pointer-type data atomically (i.e. intptr_t), then I would rather check whether we actually need non-long support at all in user-space. In case we don't, I would simply reply on the existing implementation of asm-*/atomic.h + the set / get extensions you provide. I use both atomic_t and atomic_ptr_t for the implementation of user-space mutexes. The problem is that I am constrained by the size of pthread_mutex_t, so the control block read-write locks implementation use atomic_t. Ok, makes sense. Let's just fix the namespace then, so that we don't get the feeling of having duplicate sets of operations. That said, there is just enough room for replacing the atomic_t with an atomic_long_t. So, we can make xnarch_atomic_t a long type. Have you anything agains making an xnarch_atomic_ptr_t ? No objection, just let us call it xnarch_atomic_intptr_t to ANSIfy this a bit more, and clearly state that we need this type to hold a pointer into an integer value, and operate atomically on it. Ok. The current type defined in asm-arm/atomic.h is atomic_counter_t. Should I rename this xnarch_atomic_t ? I ask this now, because I am going to do search and replaces of atomic_ all over my changes, so, I prefer to know before. -- Gilles. ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
[Xenomai-core] [3/9] Define more atomic operations in user-space
This patch implements the _read, _set, and _cmpxchg operations on atomic_long_t
and atomic_ptr_t in user-space in include/asm-generic/atomic.h which should be
included at the end of include/asm-*/atomic.h after the definition of the same
operations for the atomic_t type and atomic64_t type on 64 bits platforms.
These operations are the basic operations used by user-space mutexes. Maybe we
should add the xnarch_ prefix ?
---
Makefile.am |2 -
atomic.h| 68
2 files changed, 69 insertions(+), 1 deletion(-)
Index: include/asm-generic/atomic.h
===
--- include/asm-generic/atomic.h(revision 0)
+++ include/asm-generic/atomic.h(revision 0)
@@ -0,0 +1,68 @@
+#ifndef ATOMIC_H
+#define ATOMIC_H
+
+#ifndef __KERNEL__
+#include bits/wordsize.h
+#if __WORDSIZE == 64
+typedef atomic64_t atomic_long_t;
+
+static inline long atomic_long_read(atomic_long_t *l)
+{
+atomic64_t *v = (atomic64_t *)l;
+
+return (long)atomic64_read(v);
+}
+
+static inline void atomic_long_set(atomic_long_t *l, long i)
+{
+atomic64_t *v = (atomic64_t *)l;
+
+atomic64_set(v, i);
+}
+
+#define atomic_long_cmpxchg(l, old, new) \
+(atomic64_cmpxchg((atomic64_t *)(l), (old), (new)))
+
+#else /* __WORDSIZE == 32 */
+typedef atomic_t atomic_long_t;
+
+static inline long atomic_long_read(atomic_long_t *l)
+{
+atomic_t *v = (atomic_t *)l;
+
+return (long)atomic_read(v);
+}
+
+static inline void atomic_long_set(atomic_long_t *l, long i)
+{
+atomic_t *v = (atomic_t *)l;
+
+atomic_set(v, i);
+}
+
+#define atomic_long_cmpxchg(l, old, new) \
+(atomic_cmpxchg((atomic_t *)(l), (old), (new)))
+#endif /* __WORDSIZE == 32 */
+#endif /* __KERNEL__ */
+
+typedef atomic_long_t atomic_ptr_t;
+
+static inline void *atomic_ptr_read(atomic_ptr_t *l)
+{
+atomic_long_t *v = (atomic_long_t *)l;
+
+return (void *)atomic_long_read(v);
+}
+
+static inline void atomic_ptr_set(atomic_ptr_t *l, void *i)
+{
+atomic_long_t *v = (atomic_long_t *)l;
+
+atomic_long_set(v, (long)i);
+}
+
+#define atomic_ptr_cmpxchg(l, old, new) \
+(void *)(atomic_long_cmpxchg((atomic_long_t *)(l), \
+ (long)(old), (long)(new)))
+
+#endif /* ATOMIC_H */
Index: include/asm-generic/Makefile.am
===
--- include/asm-generic/Makefile.am (revision 3718)
+++ include/asm-generic/Makefile.am (working copy)
@@ -1,5 +1,5 @@
includesubdir = $(includedir)/asm-generic
-includesub_HEADERS = arith.h features.h hal.h syscall.h system.h wrappers.h
+includesub_HEADERS = arith.h features.h hal.h syscall.h system.h wrappers.h
atomic.h
SUBDIRS = bits
--
Gilles.
___
Xenomai-core mailing list
Xenomai-core@gna.org
https://mail.gna.org/listinfo/xenomai-core
