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". :)


Siemens AG, Corporate Technology, CT T DE IT 1
Corporate Competence Center Embedded Linux

Xenomai-core mailing list

Reply via email to