Re: [Xenomai-core] [pull request] Signals support.

[Gilles Chanteperdrix <gilles.chanteperdrix@xenomai.org>]

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