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

Reply via email to