All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jan Kiszka <jan.kiszka@domain.hid>
To: Gilles Chanteperdrix <gilles.chanteperdrix@xenomai.org>
Cc: Xenomai core <Xenomai-core@domain.hid>
Subject: Re: [Xenomai-core] [pull request] Signals support.
Date: Wed, 02 Dec 2009 09:39:56 +0100	[thread overview]
Message-ID: <4B1627DC.30300@domain.hid> (raw)
In-Reply-To: <4B15AFC0.6020805@domain.hid>

[-- Attachment #1: Type: text/plain, Size: 1677 bytes --]

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


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 257 bytes --]

  parent reply	other threads:[~2009-12-02  8:39 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-12-02  0:07 [Xenomai-core] [pull request] Signals support Gilles Chanteperdrix
2009-12-02  0:18 ` Gilles Chanteperdrix
2009-12-02  8:39 ` Jan Kiszka [this message]
2009-12-02  9:15   ` Gilles Chanteperdrix
2009-12-02  9:19   ` Jan Kiszka
2009-12-02 16:19     ` Gilles Chanteperdrix
2009-12-02 16:34       ` Jan Kiszka
2009-12-02 16:43         ` Gilles Chanteperdrix

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4B1627DC.30300@domain.hid \
    --to=jan.kiszka@domain.hid \
    --cc=Xenomai-core@domain.hid \
    --cc=gilles.chanteperdrix@xenomai.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.