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

Reply via email to