On Tue, 2009-09-29 at 19:50 +0200, Gilles Chanteperdrix wrote:
> During my flights and connections, I had a thought about this primary
> mode signals issue.
> Since the needs in term of primary mode signals greatly depends on what
> the skins want to do with it (native wants hooks, posix wants posix
> conformant signals), I think as much work as possible should be done in
> the nucleus and skins implementation, not in the I-pipe (as usual). So,
> I propose to:
> 1- add an I-pipe SIGNAL_PENDING event
> 2- add a bit somewhere in the task_struct or thread_info stuctures
> indicating that signals are pending
> 3- add a service to mark the bit, like:
> int ipipe_mark_signal_pending(struct task_struct *task);
> 4- in entry.S, when going back to user-space, test and clear the bit is
> set, and if it was set, trigger the event
> 5- implement services allowing to run a callback with some cookie when
> returning to user-space, we may also need to be able to push on stack
> some arguments that should be passed to the callback, (we need this
> service internally anyway to push the pt_regs structure on stack, so
> that the calling context can be restored after execution of the
> callback, and we need a little help from user-space for this
> restoration, probably in bind.h).
What bothers me is that we would duplicate what the kernel does in
do_signal() for most architectures, and go through many hops from the
actual signal notification to the execution of the handler. What about
delaying the logic a bit: pass userland a signal-pending information on
its way back from a syscall, to be detected by the XENOMAI_SYSCALL code
instead. If that notification flag is raised, the required information
to run the user-space handler would have been made available by the
nucleus as well, so that XENOMAI_SYSCALL would just have to act as a
trampoline to that handler.
struct xnsigdata sigdata;
mov reg, sysnr
mov reg, sysarg
mov reg, sigdata
mov __retval, reg
Granted, we should take care of keeping code inlining under control, to
prevent binary code bloat.
Xenomai currently uses only 5 argument registers to syscalls, so we
could dedicate the 6th one to hold the sigdata reference. On the
nucleus-side, return paths from the high/lo syscall stages handlers
would have to include the signal propagation code, and copy the required
data to the sigdata area when a (nucleus-originated) signal is pending.
Whether the nucleus or the skin library should hold the handlers
addresses is debatable as well; actually, I see no point in making the
kernel aware of this, if it takes no part in building a signal stack
I did not analyze how well this approach maps to the POSIX/siginfo
requirements though, in terms of context information to be made
available to the user handler.
> 6- The nucleus would then propose to register per-skin callbacks,
> subscribe to the SIGNAL_PENDING event, and dispatch a pending signal to
> all the skins which are currently expecting it. The skins would do the
> callbacks housekeeping at their level.
> The critical point is clearly point 5, and it is still a bit fuzzy. At
> least, I think I know how I would do it on ARM, but I do not know how to
> package the services in such a way that it would tolerate differences
> between platform.
Agreed, the rest is almost trivial (famous last words).
> It is unclear, for instance whether some or all
> platforms may need an additional syscall to restore the original context
> due to the need of running in privileged mode to restore some registers
Yes, some do require this, e.g. via sys_sigreturn and sys_rt_sigreturn.
Another upside of running the handler from the syscall wrapper is tht
would not need any syscall for unwinding the signal stack frame.
> Ok, now that I think about it, an additional syscall would be the
> most portable way, but also a bit slow.
> What do you think?
Xenomai-core mailing list