Gilles Chanteperdrix wrote:
> 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 would specialize it more actually so that it really resembles the vanilla
futex support, i.e. a basic object implementing the required operations to
provide mutually exclusive access, working on a pinned memory area shared
between kernel and userland. AFAICS, the current patchset implements the pinned
memory support in the nucleus, but not the operations, which remain a per-skin
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.
My concern boils down to: how much of the POSIX implementation, beyond the
cb_lock stuff, would have to be duplicated to get the same support ported to,
say the VxWorks semM services?
Xenomai-core mailing list