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
