Re: [Xenomai-core] RFC: primary mode signals design.
On Thu, 2009-10-01 at 14:22 +0200, Gilles Chanteperdrix wrote: > Philippe Gerum wrote: > > On Thu, 2009-10-01 at 12:17 +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 > >> Maybe we can re-use the linux kernel code? Maybe we can even make that > >> code platform independent and put it in the nucleus, using the xnregs* > >> macros, and maybe adding some more to alter the pt_regs structure to > >> cause the return to user-space to pass by the callback, and to be able > >> to push some data on the stack, imposing the need of a syscall to > >> restore context. > >> > > > > Quite frankly, I doubt of it. That part of the Linux code is often > > hairy, touchy, platform and context dependent, so AFAICS, maintaining > > this sort of merge over time with different kernel releases over > > multiple archs would end up in a living nightmare. > > The thing which is goddam platform dependent is the way pt_regs are > mapped to a structure passed as third argument to the posix signals with > the SA_SIGINFO flag. But in our case, this is something we will have to > cope with in the POSIX skin. Or completely forget about (I agree signals > are needed for the proper operation of posix timers, but this feature is > not really useful in a real-time application). > > Other than that, what we are talking about is just altering pt_regs::pc > and xnregs_arg1(pt_regs), then push some data on the stack (so > xncopy_to_user and altering pt_regs::sp). And adding a core skin syscall > for the way back. > I really do not see this as easy. x86 wants some fixup of the hw debug regs when watchpoints are pending, powerpc has 32/64 bit deps when unwinding the sigstack, not to speak of the very different ways blackfin, nios2 and others set up the sigstack. All this code is currently traversed by native kernel locking constructs, so I guess we would have to paste© most of the related bits. > Besides, the problem with your approach is that we can not pass data > between kernel and user. And this is required for the posix skin, at > least. And if we want a generic way to pass arguments to the user-space > callback (I mean, even in the case of the native skin switch hook, you > have to pass the ids of the switched tasks). > No issue in having the sigdata block being a union of possible per-skin structs. This is low core code, we can make it evolve as requirements arise without impacting outer interfaces. -- Philippe. ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] RFC: primary mode signals design.
Philippe Gerum wrote: > On Thu, 2009-10-01 at 12:17 +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 >> Maybe we can re-use the linux kernel code? Maybe we can even make that >> code platform independent and put it in the nucleus, using the xnregs* >> macros, and maybe adding some more to alter the pt_regs structure to >> cause the return to user-space to pass by the callback, and to be able >> to push some data on the stack, imposing the need of a syscall to >> restore context. >> > > Quite frankly, I doubt of it. That part of the Linux code is often > hairy, touchy, platform and context dependent, so AFAICS, maintaining > this sort of merge over time with different kernel releases over > multiple archs would end up in a living nightmare. The thing which is goddam platform dependent is the way pt_regs are mapped to a structure passed as third argument to the posix signals with the SA_SIGINFO flag. But in our case, this is something we will have to cope with in the POSIX skin. Or completely forget about (I agree signals are needed for the proper operation of posix timers, but this feature is not really useful in a real-time application). Other than that, what we are talking about is just altering pt_regs::pc and xnregs_arg1(pt_regs), then push some data on the stack (so xncopy_to_user and altering pt_regs::sp). And adding a core skin syscall for the way back. Besides, the problem with your approach is that we can not pass data between kernel and user. And this is required for the posix skin, at least. And if we want a generic way to pass arguments to the user-space callback (I mean, even in the case of the native skin switch hook, you have to pass the ids of the switched tasks). -- Gilles ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] RFC: primary mode signals design.
On Thu, 2009-10-01 at 12:17 +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 > > Maybe we can re-use the linux kernel code? Maybe we can even make that > code platform independent and put it in the nucleus, using the xnregs* > macros, and maybe adding some more to alter the pt_regs structure to > cause the return to user-space to pass by the callback, and to be able > to push some data on the stack, imposing the need of a syscall to > restore context. > Quite frankly, I doubt of it. That part of the Linux code is often hairy, touchy, platform and context dependent, so AFAICS, maintaining this sort of merge over time with different kernel releases over multiple archs would end up in a living nightmare. -- Philippe. ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] RFC: primary mode signals design.
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. > -- Philippe. ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] RFC: primary mode signals design.
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 Maybe we can re-use the linux kernel code? Maybe we can even make that code platform independent and put it in the nucleus, using the xnregs* macros, and maybe adding some more to alter the pt_regs structure to cause the return to user-space to pass by the callback, and to be able to push some data on the stack, imposing the need of a syscall to restore context. -- Gilles ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] RFC: primary mode signals design.
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. -- Gilles ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] RFC: primary mode signals design.
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.
e.g.
struct xnsigdata sigdata;
#define XENOMAI_SYSCALL()
({
mov reg, sysnr
mov reg, sysarg
mov reg, sigdata
syscall-op
mov __retval, reg
if (sigdata.present)
sigdata.handler(sigdata.siginfo);
__retval;
})
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
frame.
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
> value.
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?
>
--
Philippe.
___
Xenomai-core mailing list
Xenomai-core@gna.org
https://mail.gna.org/listinfo/xenomai-core
