From: Jan Kiszka <jan.kiszka@siemens.com>
To: Gilles Chanteperdrix <gilles.chanteperdrix@xenomai.org>
Cc: Xenomai <xenomai@xenomai.org>
Subject: Re: [Xenomai] Xenomai 3: kill() to non-Xenomai PIDs
Date: Fri, 16 Oct 2015 17:50:25 +0200 [thread overview]
Message-ID: <56211CC1.2030604@siemens.com> (raw)
In-Reply-To: <20151016153424.GQ16010@hermes.click-hack.org>
On 2015-10-16 17:34, Gilles Chanteperdrix wrote:
> On Fri, Oct 16, 2015 at 05:28:07PM +0200, Jan Kiszka wrote:
>> On 2015-10-16 17:22, Philippe Gerum wrote:
>>> On 10/16/2015 04:56 PM, Jan Kiszka wrote:
>>>> On 2015-10-16 16:49, Jan Kiszka wrote:
>>>>> Hi,
>>>>>
>>>>> kill() is currently handled by libcobalt such that PIDs <= 0 are
>>>>> forwarded to Linux and PIDs > 0 are considered to target only Xenomai
>>>>> threads. But what if the user wants to address a regular Linux task from
>>>>> within a Xenomai application? Shouldn't we retry kill via the Linux path
>>>>> if Xenomai's syscall reports ESRCH?
>>>>>
>>>>
>>>> IOW:
>>>>
>>>> diff --git a/lib/cobalt/signal.c b/lib/cobalt/signal.c
>>>> index aac4059..7e03301 100644
>>>> --- a/lib/cobalt/signal.c
>>>> +++ b/lib/cobalt/signal.c
>>>> @@ -99,6 +99,10 @@ COBALT_IMPL(int, kill, (pid_t pid, int sig))
>>>>
>>>> ret = XENOMAI_SYSCALL2(sc_cobalt_kill, pid, sig);
>>>> if (ret) {
>>>> + /* Retry with regular kill is no RT target was found. */
>>>> + if (ret == -ESRCH)
>>>> + return __STD(kill(pid, sig));
>>>> +
>>>> errno = -ret;
>>>> return -1;
>>>> }
>>>>
>>>> Jan
>>>>
>>>
>>> This may break code that sends signal 0 to detect whether a rt thread
>>> exists (like copperplate does), which is the reason for the lack of
>>> forwarding IIRC. (ret == -ESRCH && sig) would be required to forward
>>> without breaking such assumption.
>>
>> That still breaks POSIX (what if the user wants to test for a non-rt
>> thread, like this is possible under regular Linux?). Can't copperplate
>> be changed to bypass the wrapper?
>
> If I have understood the "xenomai 3" philosophy, is not an
> application which wants to use the standard call supposed to use the
> __STD prefix, or not use the wrapping at all ?
That's also a theoretical option, but should only be used if we can't
fix the limitation otherwise. The more exceptions we define, the less
portable we become for POSIX/Linux applications.
Jan
--
Siemens AG, Corporate Technology, CT RTC ITP SES-DE
Corporate Competence Center Embedded Linux
prev parent reply other threads:[~2015-10-16 15:50 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-10-16 14:49 [Xenomai] Xenomai 3: kill() to non-Xenomai PIDs Jan Kiszka
2015-10-16 14:56 ` Jan Kiszka
2015-10-16 15:22 ` Philippe Gerum
2015-10-16 15:28 ` Jan Kiszka
2015-10-16 15:31 ` Philippe Gerum
2015-10-16 15:57 ` Jan Kiszka
2015-10-16 16:00 ` Philippe Gerum
2015-10-16 16:03 ` Jan Kiszka
2015-10-16 16:06 ` Philippe Gerum
2015-10-16 16:07 ` Philippe Gerum
2015-10-16 15:34 ` Gilles Chanteperdrix
2015-10-16 15:50 ` Jan Kiszka [this message]
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=56211CC1.2030604@siemens.com \
--to=jan.kiszka@siemens.com \
--cc=gilles.chanteperdrix@xenomai.org \
--cc=xenomai@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.