On 2015-10-16 18:00, Philippe Gerum wrote:
> On 10/16/2015 05:57 PM, Jan Kiszka wrote:
>> On 2015-10-16 17:31, Philippe Gerum wrote:
>>> On 10/16/2015 05:28 PM, 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?
>>>>
>>>
>>> Probably, yes.
>>>
>>
>> Looking at cluster_probe, I wonder if there is actually a problem.
>> Doesn't that code also run over mercury? Then kill(pid, 0) also targets
>> the whole system, not just a set of Xenomai applications.
>
> Over mercury, the whole system is the rt domain.
>
> Or do we need
>> to ensure that the caller is not migrated to Linux needlessly under
>> cobalt? IOW: can that probing happen under RT constraints?
>>
>
> It does with clusters. In general, no restriction on the calling domain
> should exist for this low level interface.
Ok, will handle that path cobalt-specific then.
>
>> The same applies for me to the other users of the kill-based probing
>> pattern (copperplate/heapobj-pshared.c and copperplate/regd/fs-common.c).
But these are fine, no?
Jan
--
Siemens AG, Corporate Technology, CT RTC ITP SES-DE
Corporate Competence Center Embedded Linux
_______________________________________________
Xenomai mailing list
Xenomai@xenomai.org
http://xenomai.org/mailman/listinfo/xenomai
