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
> 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
Xenomai-core mailing list