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
