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
>> > 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
>> > 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
>> has been already designed to support set, get, xchg and the like, in both
>> 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
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.
Xenomai-core mailing list