Philippe Gerum wrote:
> 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;
> 
> Would be a nightmare, I think. Way too many paths are involved in the
> vanilla kernel, and this would be overkill wrt what we want to do.
> Actually, what we need is basically exposing the nucleus signal
> interface to user-space, and map Linux RT signals over nucleus signals.
> Other (non-RT) Linux signals would keep on being handled in secondary
> mode the way they are now.
> 
>> - 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.
> 
> A (maybe easier) third option would be to generalize some kind of
> pseudo-asynchronous call support, with a worker thread operating on a
> dedicated priority level inside applications registering for
> asynchronous notifications. The kernel-side would handle the server
> wakeups, providing a unified interface for pending on hooks, signals,
> watchdogs etc. It would also need to properly multiplex those events
> notified from within the skins, and wake up the right pending server in
> user-space, which would in turn fire the user provided handler, all in
> primary mode. In any case, this would not be more costly latency-wise
> than implementing mere callouts, since most of the switching cost comes
> from the MMU switch, which we would have to do in both cases, anyway.

We would need a "shadow" priority level for each real one so that those
handlers do not cause any priority inversions (the main RT issue of
servers). Moreover, it would require a bulk of extra threads, actually
one per used prio level, to handle all those calls with the correct
priority. My feeling: too costly, memory-wise.

Jan

Attachment: signature.asc
Description: OpenPGP digital signature

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

Reply via email to