On 7/19/19 12:26 PM, Richard Weinberger via Xenomai wrote:
> Hi!
> 
> Is there a way in Xenomai 3 to have a signal alike notification?

Yes, but not async. Only the sigwait*() interface is available (async
notification does not mix well with requirement for deterministic
behavior of rt code, it's even worse when it comes to POSIX signal
semantics).

> 
> The Xenomai 2 code base I work on needs a way to get exceptions such
> as #DB and #BP
> delivered to a RT_TASK in real time context.

#DB and #BP should cause a switch to secondary mode for the receiving
task. Is this mechanism a way to handle this directly from primary mode?

> For Xenomai 2 they implemented a subset of regular RT-signals which
> work in real time context.
> So the RT_TASK could register a signal handler for #DB on x86.
> 
> Before I start porting this feature to Xenomai 3 (I'll happily publish
> these patches) I want
> to sort out whether this can be achieved with stock features or
> minimal adoptions.
> 

Duplicating the signal trampoline stuff for the purpose of delivering
signals from primary mode directly from the receiving context is likely
to be ugly. Another option would be to do that on return from the
syscall trampoline, but this would require arch-dependent code in the
fast path, which would not be pretty either.

FWIW, here is the way I would convert any trap to a POSIX signal the
cobalt API could deliver via the existing sigwait interface, in order to
enable some kind of health monitoring thread:

- I would divert one of the legit POSIX signals (1 ... _NSIG) for
conveying such information (SIGUSRx?).

- in handle_exception() (posix/process.c), I would emit that signal via
the __cobalt_sigqueue() interface, using sigval to carry the trap code
(e.g. #DB). Siginfo's si_pid would be automatically set there to the
faulting process pid.

This would implement a group-targeted signal, which means that any
thread waiting for that event would receive it, along with the fault
code. Otherwise, the event would be queued until some thread eventually
issues sigwait() for it (e.g. the HM thread returning from a previous
signal handling).

-- 
Philippe.

Reply via email to