All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jan Kiszka <jan.kiszka@siemens.com>
To: Philippe Gerum <rpm@xenomai.org>
Cc: Xenomai <xenomai@xenomai.org>
Subject: Re: dovetail: add prctl() call form
Date: Tue, 9 Nov 2021 19:27:44 +0100	[thread overview]
Message-ID: <5fae03f0-0129-05b6-fcce-0be07707a501@siemens.com> (raw)
In-Reply-To: <87k0hhdwkn.fsf@xenomai.org>

On 09.11.21 14:35, Philippe Gerum wrote:
> 
> Jan Kiszka <jan.kiszka@siemens.com> writes:
> 
>> On 09.11.21 11:23, Philippe Gerum wrote:
>>>
>>> Jan Kiszka <jan.kiszka@siemens.com> writes:
>>>
>>>> On 08.11.21 18:57, Philippe Gerum wrote:
>>>>>
>>>>> Jan Kiszka <jan.kiszka@siemens.com> writes:
>>>>>
>>>>>> Hi Philippe,
>>>>>>
>>>>>> this dovetail commit makes the pipeline go red, crashing the kernels
>>>>>> (e.g. [1][2]). I hope this is something we can quickly fix in dovetail,
>>>>>> maybe via a config option?
>>>>>>
>>>>>> Jan
>>>>>>
>>>>>> [1] https://source.denx.de/Xenomai/xenomai-images/-/jobs/348118#L966
>>>>>> [2] https://source.denx.de/Xenomai/xenomai-images/-/jobs/348121#L1429
>>>>>
>>>>> Cobalt needs some update to cope with this now. I'll send a fix either
>>>>> way (dovetail or xenomai) tomorrow morning.
>>>>
>>>> This should be fixed in dovetail - API breakage. We can update Xenomai
>>>> later, along with enabling this feature again.
>>>>
>>>
>>> We now have a change in the Dovetail tree which handles the fact that
>>> some Dovetail-based core might lag behind a bit API-wise regarding the
>>> new prctl-based call form. Since this simplifies the handling for any
>>> companion core in that particular case, this seems legitimate to add
>>> it. Tested on kvm-x86, -aarch64, and i.MX6-sabre with both Cobalt and
>>> EVL cores. Both test suites run properly, so far so good.
>>
>> I'm not against this change, but activating it is no Xenomai 3.2
>> material as it will break the ABI.
> 
> No, the ABI has never been affected by this series, the old call form
> Cobalt uses is still supported, the new prctl() call form is a mere
> addition, not a replacement. The problem did only affect the kernel
> interface between the pipeline core and Cobalt, which is strictly a
> kernel API issue, not revealed by my tests mainly with Xenomai4/EVL
> unfortunately.

The whole purpose of having this addition is using it. And that does
make a lot of sense, as you described. So the plan is to activate AND
use this feature in Xenomai 3.3 - with the aforementioned impact on the ABI.

Xenomai 3.2 will continue to use the old syscall range extension scheme,
thus as no need and no desire to enable reporting of prctl calls to the
core. Therefore, Dovetail should continue to refrain from doing that for
Xenomai 3.2. The easiest way to achieve that is making the extension
build-time configurable. Other cores can then still enable it for their
*use*, and the fresh Xenomai 3.2 release will not break over the next
dovetail patch revision (which is urgently needed do to the apic-ack fix).

Makes sense?

I really like to avoid avoid diverging developments again, but stability
trumps features and would enforce this if we cannot find a better solution.

Thanks,
Jan

-- 
Siemens AG, T RDA IOT
Corporate Competence Center Embedded Linux


  reply	other threads:[~2021-11-09 18:27 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-11-08 17:39 dovetail: add prctl() call form Jan Kiszka
2021-11-08 17:57 ` Philippe Gerum
2021-11-08 18:00   ` Jan Kiszka
2021-11-09 10:23     ` Philippe Gerum
2021-11-09 10:54       ` Jan Kiszka
2021-11-09 13:35         ` Philippe Gerum
2021-11-09 18:27           ` Jan Kiszka [this message]
2021-11-10  7:38             ` Philippe Gerum
2021-11-10  8:45               ` Jan Kiszka
2021-11-10  8:58                 ` Philippe Gerum
2021-11-10 11:03                   ` Jan Kiszka
2021-11-10 11:14                     ` Philippe Gerum
2021-11-10 12:16                       ` Jan Kiszka
2021-11-10 14:59                         ` Philippe Gerum

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=5fae03f0-0129-05b6-fcce-0be07707a501@siemens.com \
    --to=jan.kiszka@siemens.com \
    --cc=rpm@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.