From mboxrd@z Thu Jan 1 00:00:00 1970 Message-ID: <4B16939E.8040505@domain.hid> Date: Wed, 02 Dec 2009 17:19:42 +0100 From: Gilles Chanteperdrix MIME-Version: 1.0 References: <4B15AFC0.6020805@domain.hid> <4B1627DC.30300@domain.hid> <4B16310E.1080306@domain.hid> In-Reply-To: <4B16310E.1080306@domain.hid> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [Xenomai-core] [pull request] Signals support. List-Id: Xenomai life and development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Jan Kiszka Cc: Xenomai core 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