Re: [Xenomai-help] Handling Linux Signals in primary domain context

[Philippe Gerum <rpm@xenomai.org>]

On Wed, 2010-06-02 at 14:02 +0200, Daniele Nicolodi wrote:
> On 02/06/10 11:15, Philippe Gerum wrote:
> 
> > Actually, we could extend this logic and forge a stack frame to return
> > to the preempted application code via some userland trampoline code,
> > doing the switch:
> > 
> > [watchdog trigger]
> > 	forge_return_frame(on =regs->sp, to =regs->pc);
> > 	regs->pc = __oops_I_did_it_again;
> > 
> > __oops_I_did_it_again:
> > 	__xn_migrate(LINUX_DOMAIN);
> > 	ret (via forged frame)
> > 
> > The thing is, that this brings in some arch-dep code to forge a stack
> > frame (like the kernel uses for signals), that should rather live in the
> > pipeline core.
> 
> Am I to naive thinking that this solution would let the user space
> choose what to do when the watchdog interrupts the current thread? In
> your example, it would be enough to assign to __ops_I_did_it_again a
> function pointer to the function that has to be executed.
> 
> Probably there will be hard constraint on what this function can do, but
> it would be a nice feature for debugging and for solving application
> specific issues.

If your question is related to handling a watchdog trigger in a
syscall-less runaway loop, that method would likely allow for a user
intercept via some hook, yes. Everything sensible that helps debugging
will do.

> 
> Cheers,


-- 
Philippe.