Re: [Xenomai-core] yet another test tool

[Jan Kiszka <jan.kiszka@domain.hid>]

[-- Attachment #1: Type: text/plain, Size: 1958 bytes --]

Gilles Chanteperdrix wrote:
> Jan Kiszka wrote:
>  > (...)As Xenomai does not support hard-RT signal delivery yet (...)
> 
> This is the next feature missing to the POSIX skin. I would like to
> implement this, but I am not sure which way to go :
> - either, if it is possible, getting Linux signals services to run in
>   every domain at Adeos level, by replacing spinlocks with spinlocks_hw
>   and such kind of tricks;
> - or adding a generic service at the adeos layer (a hook called when
>   returning to user-space), building a generic user-space signals
>   service at the nucleus level, and finally building all posix signals
>   services on top of this.
> 
> The first approach guarantees the best integration with Linux, but
> potentially add sections in Linux that are not preemptible by any
> Xenomai skin. With the second approach, all services related to signals
> have to be reimplemented plus some shortcuts to have standard user-space
> tools such as "kill" working.
> 

The preemptibility of the Linux signal code path heavily depends on the
tasklist_lock, and that was still an issue even for PREEMPT_RT with all
their modifications the last time I checked their code more thoroughly
(~2 months ago). Meanwhile, things may have improved for that tree, but
I doubt that this is already in mainline, not to speak of older 2.6 or
even 2.4 kernels.

As a first step, I would vote for establishing that generic service to
redirect the userspace return path to some arbitrary handler in hard-RT
context. Then we can think about how to handle signal injection from
Linux vs. injection from Xenomai gracefully.

> 
>  > 
>  > What do you think, is it worth including as a POSIX counterpart for
>  > testsuite/latency?
> 
> There are a few details that I do not like about this tool, but we may
> take it, and fix the details later.

It's a real hack, isn't it ;)? But what precisely do you mean?

Jan


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 252 bytes --]