Re: [Xenomai-core] [pull request] Signals support.
Gilles Chanteperdrix wrote: Hi, here come the pull request for user-space signals support. The simple solution; handling signals upon system call return, has been implemented since the other solution (handling signals upon any return to user-space) required to change the I-pipe patch, and so made the upcoming 2.5 only compatible with newer patches. We pass to kernel-space a sixth argument which is a pointer where information about received signals is stored by kernel. The only architecture for which the implementation is peculiar is x86_32, because the register used as sixth argument is ebp, also used for the libc backtrace function implementation, so I tried to find a solution which makes backtracing still possible (otherwise we would have said bye-bye to involuntary mode changes chasing with SIGXCPU) without breaking too many things. I'm still digging through the code. A few minor remarks regarding the user space side so far: XENOMAI_DO_SYSCALL becomes quite bloated now, and it's inlined. Did you check that the fast path (ie. no signal) only contains one conditional branch when the compiler is done with optimizing? If not (I suspect so), the code should be refactored to look more like restart: do_syscall if unlikely(sigs.nsigs) res = handle_signals if res == -ERESTART goto restart Moreover, the inner while loop over sigs.remaining should be moved into a shared function as well. I don't see why it should be instantiated at each and every syscall invocation site. Am I right, there is no skin (except the test skin) using this feature so far? Jan signature.asc Description: OpenPGP digital signature ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] [pull request] Signals support.
Jan Kiszka wrote: Gilles Chanteperdrix wrote: Hi, here come the pull request for user-space signals support. The simple solution; handling signals upon system call return, has been implemented since the other solution (handling signals upon any return to user-space) required to change the I-pipe patch, and so made the upcoming 2.5 only compatible with newer patches. We pass to kernel-space a sixth argument which is a pointer where information about received signals is stored by kernel. The only architecture for which the implementation is peculiar is x86_32, because the register used as sixth argument is ebp, also used for the libc backtrace function implementation, so I tried to find a solution which makes backtracing still possible (otherwise we would have said bye-bye to involuntary mode changes chasing with SIGXCPU) without breaking too many things. I'm still digging through the code. A few minor remarks regarding the user space side so far: XENOMAI_DO_SYSCALL becomes quite bloated now, and it's inlined. Did you check that the fast path (ie. no signal) only contains one conditional branch when the compiler is done with optimizing? If not (I suspect so), the code should be refactored to look more like restart: do_syscall if unlikely(sigs.nsigs) res = handle_signals if res == -ERESTART goto restart The test for sigs.nsigs is done in the inline xnsig_dispatch function, which jumps to the out-of-line dispatch function only if there are really some signals to handle. Then comes the test while (sigs.nsigs sigs.remaining), so my hope was that the compiler would optimize the jump-after-conditional-to-a-conditional-with-same-condition, this is a pretty standard optimization, but have not checked that it did so. As for the goto, I have nothing against gotos when they are needed, but in that case we can easily avoid it with a do while loop. Moreover, the inner while loop over sigs.remaining should be moved into a shared function as well. I don't see why it should be instantiated at each and every syscall invocation site. The point is that when there are more than a fixed amount of signals queued (16, arbitrarily fixed to allow for some queueing, but avoid taking too much room on stack), we emit a second inner syscall to get them. And the way to emit this second syscall is platform-dependent. The code at this point is pretty much the same on all platforms... except on x86_32, though it is probably possible to factor this out with clever macros. Am I right, there is no skin (except the test skin) using this feature so far? Yes, we break the ABI first, and we will implement the posix skin signals after the initial 2.5 release. Because the signals data union is part of the ABI, it has already been given the posix siginfo structure size. Since this structure is pretty large, I expected no skin to need more room. -- Gilles. ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] [pull request] Signals support.
Jan Kiszka wrote: Gilles Chanteperdrix wrote: Hi, here come the pull request for user-space signals support. The simple solution; handling signals upon system call return, has been implemented since the other solution (handling signals upon any return to user-space) required to change the I-pipe patch, and so made the upcoming 2.5 only compatible with newer patches. We pass to kernel-space a sixth argument which is a pointer where information about received signals is stored by kernel. The only architecture for which the implementation is peculiar is x86_32, because the register used as sixth argument is ebp, also used for the libc backtrace function implementation, so I tried to find a solution which makes backtracing still possible (otherwise we would have said bye-bye to involuntary mode changes chasing with SIGXCPU) without breaking too many things. I'm still digging through the code. A few minor remarks regarding the user space side so far: XENOMAI_DO_SYSCALL becomes quite bloated now, and it's inlined. Did you check that the fast path (ie. no signal) only contains one conditional branch when the compiler is done with optimizing? If not (I suspect so), the code should be refactored to look more like restart: do_syscall if unlikely(sigs.nsigs) res = handle_signals if res == -ERESTART goto restart Moreover, the inner while loop over sigs.remaining should be moved into a shared function as well. I don't see why it should be instantiated at each and every syscall invocation site. Am I right, there is no skin (except the test skin) using this feature so far? Next question: The signal delivery latency is naturally affected by the syscall invocation frequency of the target thread, right? Ie. no syscall, no signal. Once we offer RT signals via the skin, this limitation should be prominently documented. Jan signature.asc Description: OpenPGP digital signature ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] [pull request] Signals support.
Jan Kiszka wrote: Jan Kiszka wrote: Gilles Chanteperdrix wrote: Hi, here come the pull request for user-space signals support. The simple solution; handling signals upon system call return, has been implemented since the other solution (handling signals upon any return to user-space) required to change the I-pipe patch, and so made the upcoming 2.5 only compatible with newer patches. We pass to kernel-space a sixth argument which is a pointer where information about received signals is stored by kernel. The only architecture for which the implementation is peculiar is x86_32, because the register used as sixth argument is ebp, also used for the libc backtrace function implementation, so I tried to find a solution which makes backtracing still possible (otherwise we would have said bye-bye to involuntary mode changes chasing with SIGXCPU) without breaking too many things. I'm still digging through the code. A few minor remarks regarding the user space side so far: XENOMAI_DO_SYSCALL becomes quite bloated now, and it's inlined. Did you check that the fast path (ie. no signal) only contains one conditional branch when the compiler is done with optimizing? If not (I suspect so), the code should be refactored to look more like restart: do_syscall if unlikely(sigs.nsigs) res = handle_signals if res == -ERESTART goto restart Moreover, the inner while loop over sigs.remaining should be moved into a shared function as well. I don't see why it should be instantiated at each and every syscall invocation site. Ok. The second syscall is now done in the out-of-line signal handling function. Do you prefer this? It is only implemented for x86_32 since it is the problematic architecture, but if you are ok with it, I will change the other architectures. Am I right, there is no skin (except the test skin) using this feature so far? Next question: The signal delivery latency is naturally affected by the syscall invocation frequency of the target thread, right? Ie. no syscall, no signal. Once we offer RT signals via the skin, this limitation should be prominently documented. Well, if you make no syscall, your box is basically a brick. We need suspensions from time to time to get Linux running anyway. -- Gilles ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] [pull request] Signals support.
Gilles Chanteperdrix wrote: Jan Kiszka wrote: Jan Kiszka wrote: Gilles Chanteperdrix wrote: Hi, here come the pull request for user-space signals support. The simple solution; handling signals upon system call return, has been implemented since the other solution (handling signals upon any return to user-space) required to change the I-pipe patch, and so made the upcoming 2.5 only compatible with newer patches. We pass to kernel-space a sixth argument which is a pointer where information about received signals is stored by kernel. The only architecture for which the implementation is peculiar is x86_32, because the register used as sixth argument is ebp, also used for the libc backtrace function implementation, so I tried to find a solution which makes backtracing still possible (otherwise we would have said bye-bye to involuntary mode changes chasing with SIGXCPU) without breaking too many things. I'm still digging through the code. A few minor remarks regarding the user space side so far: XENOMAI_DO_SYSCALL becomes quite bloated now, and it's inlined. Did you check that the fast path (ie. no signal) only contains one conditional branch when the compiler is done with optimizing? If not (I suspect so), the code should be refactored to look more like restart: do_syscall if unlikely(sigs.nsigs) res = handle_signals if res == -ERESTART goto restart Moreover, the inner while loop over sigs.remaining should be moved into a shared function as well. I don't see why it should be instantiated at each and every syscall invocation site. Ok. The second syscall is now done in the out-of-line signal handling function. Do you prefer this? The smaller the inlined code gets, the better. It is only implemented for x86_32 since it is the problematic architecture, but if you are ok with it, I will change the other architectures. Will check, thanks. Am I right, there is no skin (except the test skin) using this feature so far? Next question: The signal delivery latency is naturally affected by the syscall invocation frequency of the target thread, right? Ie. no syscall, no signal. Once we offer RT signals via the skin, this limitation should be prominently documented. Well, if you make no syscall, your box is basically a brick. We need suspensions from time to time to get Linux running anyway. For sure. My point is that people may get the idea to build time-critical event delivery based on signals. In such cases it would make a big difference how often the destination thread issues a syscall. Also forced preemptions can extend the delivery latency, only the user space workload counts. I would not recommend such application designs, but people may get that idea when they once read RT-safe signals. :) Jan -- Siemens AG, Corporate Technology, CT T DE IT 1 Corporate Competence Center Embedded Linux ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] [pull request] Signals support.
Jan Kiszka wrote: Gilles Chanteperdrix wrote: Jan Kiszka wrote: Jan Kiszka wrote: Gilles Chanteperdrix wrote: Hi, here come the pull request for user-space signals support. The simple solution; handling signals upon system call return, has been implemented since the other solution (handling signals upon any return to user-space) required to change the I-pipe patch, and so made the upcoming 2.5 only compatible with newer patches. We pass to kernel-space a sixth argument which is a pointer where information about received signals is stored by kernel. The only architecture for which the implementation is peculiar is x86_32, because the register used as sixth argument is ebp, also used for the libc backtrace function implementation, so I tried to find a solution which makes backtracing still possible (otherwise we would have said bye-bye to involuntary mode changes chasing with SIGXCPU) without breaking too many things. I'm still digging through the code. A few minor remarks regarding the user space side so far: XENOMAI_DO_SYSCALL becomes quite bloated now, and it's inlined. Did you check that the fast path (ie. no signal) only contains one conditional branch when the compiler is done with optimizing? If not (I suspect so), the code should be refactored to look more like restart: do_syscall if unlikely(sigs.nsigs) res = handle_signals if res == -ERESTART goto restart Moreover, the inner while loop over sigs.remaining should be moved into a shared function as well. I don't see why it should be instantiated at each and every syscall invocation site. Ok. The second syscall is now done in the out-of-line signal handling function. Do you prefer this? The smaller the inlined code gets, the better. It is only implemented for x86_32 since it is the problematic architecture, but if you are ok with it, I will change the other architectures. Will check, thanks. Am I right, there is no skin (except the test skin) using this feature so far? Next question: The signal delivery latency is naturally affected by the syscall invocation frequency of the target thread, right? Ie. no syscall, no signal. Once we offer RT signals via the skin, this limitation should be prominently documented. Well, if you make no syscall, your box is basically a brick. We need suspensions from time to time to get Linux running anyway. For sure. My point is that people may get the idea to build time-critical event delivery based on signals. In such cases it would make a big difference how often the destination thread issues a syscall. Also forced preemptions can extend the delivery latency, only the user space workload counts. I would not recommend such application designs, but people may get that idea when they once read RT-safe signals. :) Ok. But if the thread receiving the syscall is suspended in primary mode, it will wake up ASAP to handle the signal, so the latency is not that great. Of course it will work if the target thread is suspended most of the time. -- Gilles ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
[Xenomai-core] [pull request] Signals support.
Hi, here come the pull request for user-space signals support. The simple solution; handling signals upon system call return, has been implemented since the other solution (handling signals upon any return to user-space) required to change the I-pipe patch, and so made the upcoming 2.5 only compatible with newer patches. We pass to kernel-space a sixth argument which is a pointer where information about received signals is stored by kernel. The only architecture for which the implementation is peculiar is x86_32, because the register used as sixth argument is ebp, also used for the libc backtrace function implementation, so I tried to find a solution which makes backtracing still possible (otherwise we would have said bye-bye to involuntary mode changes chasing with SIGXCPU) without breaking too many things. A new test, creatively called sigtest allows to unit-test the signal support. The following changes since commit 5a29ba38d7563097b73f53615fb3fcb7a7e5a6a5: Philippe Gerum (1): nucleus: initialize heap-stat_link holder are available in the git repository at: git+ssh://git.xenomai.org/xenomai-gch.git for-head Gilles Chanteperdrix (12): bind: Replace bind.h with a convenience library. skins: add per-skin user-space signal handler, and dispatch function. arm: implement signals handling powerpc: implement signals handling x86_64: implement signals handling x86_32: implement signals handling nucleus: implement kernel-space per-thread per-skin signals handling. skins: move sigshadow to libxeno_common posix: fix pthread_cond_wait restarting native: fix rt_cond_wait restarting testsuite: add user-space real-time signals unit test build: bootstrap Philippe Gerum (2): blackfin: introduce support for real-time signals nios: implement signals handling Makefile.in| 193 +- aclocal.m4 | 323 +- config/Makefile.in | 43 +- configure | 5869 configure.in |5 + doc/Makefile.in| 131 +- doc/docbook/Makefile.in| 131 +- doc/docbook/custom-stylesheets/Makefile.in | 131 +- doc/docbook/custom-stylesheets/xsl/Makefile.in | 131 +- .../custom-stylesheets/xsl/common/Makefile.in | 43 +- doc/docbook/custom-stylesheets/xsl/fo/Makefile.in | 43 +- .../custom-stylesheets/xsl/html/Makefile.in| 43 +- doc/docbook/xenomai/Makefile.in| 43 +- doc/doxygen/Makefile.in| 43 +- doc/man/Makefile.in| 215 +- doc/txt/Makefile.in| 82 +- include/Makefile.am|2 +- include/Makefile.in| 194 +- include/analogy/Makefile.in| 105 +- include/asm-arm/Makefile.in| 170 +- include/asm-arm/bits/Makefile.in | 105 +- include/asm-arm/features.h |2 +- include/asm-arm/syscall.h | 66 +- include/asm-blackfin/Makefile.in | 170 +- include/asm-blackfin/bits/Makefile.in | 105 +- include/asm-blackfin/features.h|2 +- include/asm-blackfin/syscall.h | 241 +- include/asm-generic/Makefile.in| 170 +- include/asm-generic/bits/Makefile.in | 105 +- include/asm-generic/bits/bind.h| 305 +- include/asm-generic/bits/current.h |3 + include/asm-generic/bits/sigshadow.h | 74 +- include/asm-generic/syscall.h | 58 +- include/asm-nios2/Makefile.in | 170 +- include/asm-nios2/bits/Makefile.in | 105 +- include/asm-nios2/syscall.h| 73 +- include/asm-powerpc/Makefile.in| 170 +- include/asm-powerpc/bits/Makefile.in | 105 +- include/asm-powerpc/features.h |2 +- include/asm-powerpc/syscall.h | 58 +- include/asm-sim/Makefile.in| 170 +- include/asm-sim/bits/Makefile.in | 105 +- include/asm-x86/Makefile.in| 170 +- include/asm-x86/bits/Makefile.in | 105 +- include/asm-x86/features_32.h |2 +- include/asm-x86/features_64.h |2 +- include/asm-x86/syscall.h | 219 +- include/native/Makefile.in | 105 +- include/native/cond.h |6 +- include/native/syscall.h |3
Re: [Xenomai-core] [pull request] Signals support.
Gilles Chanteperdrix wrote: Hi, here come the pull request for user-space signals support. The simple solution; handling signals upon system call return, has been implemented since the other solution (handling signals upon any return to user-space) required to change the I-pipe patch, and so made the upcoming 2.5 only compatible with newer patches. We pass to kernel-space a sixth argument which is a pointer where information about received signals is stored by kernel. The only architecture for which the implementation is peculiar is x86_32, because the register used as sixth argument is ebp, also used for the libc backtrace function implementation, so I tried to find a solution which makes backtracing still possible (otherwise we would have said bye-bye to involuntary mode changes chasing with SIGXCPU) without breaking too many things. A new test, creatively called sigtest allows to unit-test the signal support. The following changes since commit 5a29ba38d7563097b73f53615fb3fcb7a7e5a6a5: Philippe Gerum (1): nucleus: initialize heap-stat_link holder are available in the git repository at: git+ssh://git.xenomai.org/xenomai-gch.git for-head Gilles Chanteperdrix (12): bind: Replace bind.h with a convenience library. skins: add per-skin user-space signal handler, and dispatch function. arm: implement signals handling powerpc: implement signals handling This commit was credited to the wrong author, should be fixed now. -- Gilles. ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
