On Thu, Apr 24, 2008 at 9:37 AM, Gilles Chanteperdrix
<[EMAIL PROTECTED]> wrote:
>
> 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.

Actually, it may be vmalloced memory only on architectures using the
non cached heaps. So, it should be OK on PPC where vmalloc memory
causes problems, because PPC should not need non cached mapping and
will use kmalloced memory.

-- 
 Gilles

_______________________________________________
Xenomai-core mailing list
Xenomai-core@gna.org
https://mail.gna.org/listinfo/xenomai-core

Reply via email to