On Thu, 2009-10-01 at 12:06 +0200, Gilles Chanteperdrix wrote:
> Philippe Gerum wrote:
> > On Tue, 2009-09-29 at 19:50 +0200, Gilles Chanteperdrix wrote:
> >> Hi,
> >> 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.
> It will not work if the signals interrupt a task which is using the CPU
> without syscalls. With mutexes in user-space, a lot may happen in
> user-space without syscalls.
That case is 100% pathological in primary mode, since it basically
starves the whole machine from CPU, so I'm unsure this should be
considered as a desirable feature.
Xenomai-core mailing list