On Thu, Apr 24, 2008 at 9:09 AM, Jan Kiszka <[EMAIL PROTECTED]> wrote:
> Gilles Chanteperdrix wrote:
> > Hi,
> > the patch series to come for review adds support for user-space mutexes to
> > posix skin. Since I wanted this support to be available on my AT91RM9200,
> > patch series start with patches which are mainly for the ARM architecture,
> > end with reimplementation of the kernel-space and user-space mutex
> services for
> > the posix skin.
> Cool stuff!
> > Some patches brought some questions when making them, questions which will
> > discussed in the mail accompanying the patch.
> > Since I do not use quilt, some patches will inevitably mix several
> > modifications, especially the patch to ksrc/skins/posix/syscall.c. I
> > next time I will use quilt.
> > The result has only be tested in the fast (no syscall) case, to evaluate
> > performance, I will start tests trying to cover the syscall case now, and
> > you informed.
> Central question (IMHO): Do you ensure that the kernel-side atomic op on
> the mutex state can _never_ raise an exception? Or do you have some
> atomic mechanism that can handle faults?
The atomic op takes place on memory allocated on a shared xnheap. So,
it is basically vmalloc or kmalloced memory in kernel-space and is
hence garanteed to not fault. In user-space, the kernel helper
(kuser_cmpxchg) used for handling atomic_cmpxchg on ARM pre v6 has
builtin support for handling exceptions (basically, the operation is
restarted upon exception). I do not know if it will be the case for
ARM v6 or other arches, but since we are using a mapped heap, I would
expect mlockall to save us.
Xenomai-core mailing list