Re: [Xenomai-core] RFC: primary mode signals design.

2009-10-01 Thread Philippe Gerum
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


Re: [Xenomai-core] RFC: primary mode signals design.

2009-10-01 Thread Gilles Chanteperdrix
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.

2009-10-01 Thread Gilles Chanteperdrix
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.

2009-10-01 Thread Philippe Gerum
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.

2009-10-01 Thread Philippe Gerum
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.

2009-10-01 Thread Gilles Chanteperdrix
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.

2009-10-01 Thread Philippe Gerum
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 pastecopy 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