Philippe Gerum wrote:
 > Gilles Chanteperdrix wrote:
 > > The two syscalls defined in the posix skin now moved to the sys skin, they 
 > > are
 > > used in user-space by include/asm-generic/bits/bind.h and the new header
 > > include/asm-generic/bits/current.h. The global and process-specific shared 
 > > heaps
 > > are now part of this patch.
 > >
 > Is there any reason why the nucleus should not implement a full-fledged "RT
 > futex" support, instead of a toolbox to build them? I'm concerned by skins
 > reinventing their own wheel uselessly to get to the same point at the end of 
 > the
 > day; e.g. cb_lock ops seem to me fairly generic when it comes to handling
 > futexes, so I would move them upstream one level more.
 > In that respect, talking about "semaphore heaps" at nucleus level looks a 
 > bit of
 > a misnomer: if we mostly bring a service to map non-cacheable memory to
 > user-space, then we don't actually provide semaphore support.

If I understand correctly, a futex is, in xenomai terms, a way to
associate a user-space address, with an xnsynch object. I feel this
would complicate things: currently, the way I implemented user-space
mutexes for the posix skin kept the old association between the
user-space mutex, and its kernel-space companion, also used by
kernel-space operations.



Xenomai-core mailing list

Reply via email to