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 
> the
>  > posix skin. Since I wanted this support to be available on my AT91RM9200, 
> the
>  > patch series start with patches which are mainly for the ARM architecture, 
> to
>  > 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 
> be
>  > 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 
> promise,
>  > next time I will use quilt.
>  >
>  > The result has only be tested in the fast (no syscall) case, to evaluate 
> its
>  > performance, I will start tests trying to cover the syscall case now, and 
> keep
>  > 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

Reply via email to