From: Philippe Gerum <rpm@xenomai.org>
To: Jan Kiszka <jan.kiszka@siemens.com>
Cc: xenomai@xenomai.org, Hongzhan Chen <hongzhan.chen@intel.com>
Subject: Re: [PATCH 00/17] Dovetail integration - the finals
Date: Mon, 14 Jun 2021 08:24:21 +0200 [thread overview]
Message-ID: <87k0mx6k16.fsf@xenomai.org> (raw)
In-Reply-To: <a10bb646-fea6-7bbd-60f2-b02c08789dbc@siemens.com>
Jan Kiszka <jan.kiszka@siemens.com> writes:
> On 13.06.21 19:07, Philippe Gerum wrote:
>>
>> Jan Kiszka <jan.kiszka@siemens.com> writes:
>>
>>> On top, I would also still like to understand - and ideally address
>>> prior to releasing a new major version - if we cannot align the ARM
>>> syscall ABI of Xenomai to the kernel /wrt argument passing. Now is a
>>> good chance to do that.
>>
>> That would be fairly simple implementation-wise, problem though: this
>> would require to add this change to the next I-pipe/arm releases,
>> invalidating all previous I-pipe releases for 3.2 in the same move. In
>> theory, all existing I-pipe/arm patches starting from kernel 3.10 can
>> run the -next branch (although it may be better to stick with 4.14+ in
>> practice).
>>
>
> 4.14 is long dead, 4.19 could be the lowest target. Yes, that might
> involve some some complications. Maybe we could add a feature flag for
> the new ABI, start with dovetail and then look into lifting 4.19 and 5.4
> I-pipe.
>
Dovetail already follows the ARM EABI, only using a marker to
distinguish in-band syscalls from foreign ones in r7, on all archs. This
said, I plan to work on another option for conveying oob syscalls based
on prctl() asap, this would be saner than invalidating a whole range of
syscall numbers for the regular kernel. In addition, this might help
enabling tools like valgrind at little/no cost. The earlier the better
to investigate this, I'd rather not have to maintain multiple ABIs in
Dovetail.
--
Philippe.
prev parent reply other threads:[~2021-06-14 6:24 UTC|newest]
Thread overview: 25+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-06-11 18:05 [PATCH 00/17] Dovetail integration - the finals Jan Kiszka
2021-06-11 18:05 ` [PATCH 01/17] cobalt/thread: Rework kthread check for xnthread_signal Jan Kiszka
2021-06-11 18:05 ` [PATCH 02/17] cobalt/thread: Move xnthread_signal work off the stack Jan Kiszka
2021-06-11 18:05 ` [PATCH 03/17] cobalt/thread: Privatize xnthread_map to map_kthread Jan Kiszka
2021-06-11 18:05 ` [PATCH 04/17] cobalt/thread: Pull kthread inband work onto creator stack Jan Kiszka
2021-06-11 18:05 ` [PATCH 05/17] cobalt/thread: Make sure relax inband work is on a stack outliving the wakeup Jan Kiszka
2021-06-11 18:05 ` [PATCH 06/17] cobalt/thread: dovetail: keep hard irqs off on transition to in-band Jan Kiszka
2022-01-24 16:15 ` Jan Kiszka
2022-01-24 16:55 ` Philippe Gerum
2022-01-24 17:00 ` Philippe Gerum
2022-01-24 17:05 ` Jan Kiszka
2021-06-11 18:05 ` [PATCH 07/17] cobalt/sched: dovetail: prevent early scheduling on uninit runqueues Jan Kiszka
2021-06-11 18:05 ` [PATCH 08/17] cobalt/arm: dovetail: add architecture bits Jan Kiszka
2021-06-11 18:05 ` [PATCH 09/17] lib/cobalt: Reorder low_init for having cobalt_use_legacy_tsc earlier available Jan Kiszka
2021-06-11 18:05 ` [PATCH 10/17] lib/cobalt/arm: dovetail: skip detection of KUSER_TSC support Jan Kiszka
2021-06-11 18:05 ` [PATCH 11/17] lib/cobalt/arm64: " Jan Kiszka
2021-06-11 18:05 ` [PATCH 12/17] cobalt/tick: dovetail: improve accuracy of the host tick delay Jan Kiszka
2021-06-11 18:05 ` [PATCH 13/17] cobalt/tick: dovetail: Drop pointless inline specifier from pipeline_must_force_program_tick Jan Kiszka
2021-06-11 18:05 ` [PATCH 14/17] cobalt/clock: dovetail: abstract interface to hardware TSC Jan Kiszka
2021-06-11 18:05 ` [PATCH 15/17] cobalt/arm64: dovetail: add architecture bits Jan Kiszka
2021-06-11 18:05 ` [PATCH 16/17] cobalt/syscall: Account for different syscall argument marshaling Jan Kiszka
2021-06-11 18:05 ` [PATCH 17/17] ci: Add arm, arm64 and x86 dovetail targets for kernel 5.10 Jan Kiszka
2021-06-13 17:07 ` [PATCH 00/17] Dovetail integration - the finals Philippe Gerum
2021-06-13 17:12 ` Jan Kiszka
2021-06-14 6:24 ` Philippe Gerum [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=87k0mx6k16.fsf@xenomai.org \
--to=rpm@xenomai.org \
--cc=hongzhan.chen@intel.com \
--cc=jan.kiszka@siemens.com \
--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.