Xenomai 3.x over Dovetail

Xenomai 3.x over Dovetail

[Philippe Gerum]

All,

After some recent discussion with Jan, I'm joining the fray in order to
get Xenomai rebased on Dovetail, replacing the I-pipe, the in-kernel
software layer which connects the real-time (Cobalt) core to the
mainline Linux implementation. The main goal is to enable Xenomai 3.x
for the most recent LTS kernel releases, such as the upcoming v5.10. A
bit of context in the form of a Q&A:

Q: Why do we need the I-pipe to be replaced in the first place?
A: Because Dovetail - as the successor to the I-pipe - addresses
   important implementation and maintenance issues of the latter.
   Maintaining two interfaces with identical goals concurrently any
   further would make no sense, and would keep on diluting the scarce
   manpower resources we have.

Q: Why can't we just port the I-pipe to v5.10, etc.?
A: Because the aging design of the I-pipe would make this a very
   difficult task, especially when confronted to massive code churn,
   like the one which took place in the v5.8 cycle for x86. Although I'm
   not claiming the upgrade process has become trivial, Dovetail is
   certainly simpler to port to newer kernel releases than doing so for
   the I-pipe might ever be. Dovetail tracks the kernel development tip,
   runs v5.10-rc4 at the moment.

Q: What kind of I-pipe issues does Dovetail fix?
A: Basically, a better integration with the mainline kernel
   implementation, which eases the work of rebasing it on top of newer
   kernel releases. It also provides crucial built-in capabilities such
   as time and clock source management, real-time context switching and
   fpu handling shared with the common kernel implementation, which
   the real-time core does not have to care about anymore.

Q: Will switching to Dovetail have an impact on applications?
A: No, the nitty-gritty details should live into the kernel and libcobalt,
   without affecting the APIs.

Q: Will switching to Dovetail have an impact on the Xenomai ABI?
A: Yes. Therefore the changes involved will be at core of Xenomai
   3.2+. They won't be backported to Xenomai 3.1 or earlier.

Q: Which CPU architectures does Dovetail support today?
A: aarch64, aarch32 (armv7 essentially), x86_64.

== Now, to the proposed broad plan for achieving this port:

1- the ability to test the very same Cobalt code base on top of Dovetail
   or the I-pipe alternatively may go a long way toward debugging the
   port, particularly when it comes to spotting regressions. For
   achieving this, we should insert some "interrupt pipeline"
   abstraction layer into the Cobalt code. Depending on some build time
   selector, the I-pipe or Dovetail interface would be used. Initially,
   we could focus on having the I-pipe interface side working, which
   should not be prone to regression since this task is basically about
   moving code around, reorganizing the Cobalt code base.

2- once the dust has settled on moving the code around, we need to
   rework the timer management layer (xntimer) in order to switch the
   internal date and delay representation from "clock ticks" (e.g. TSC
   counts, or whatever unit some time hardware might use) to plain
   nanoseconds, in order to align on the regular kernel representation
   of time values (ktime_t, which Dovetail shares). Those changes will
   impact libcobalt as well. Bonus: once this is done, applications may
   safely get time stamps from primary mode using the fast vDSO
   mechanism via clock_gettime() for instance. In addition, variation of
   the CPU frequency (CPU_FREQ) will stop being a showstopper, since our
   time stamps would not depend on the duration of a hardware tick
   anymore.

3- then, we may flesh out and test the Dovetail side of the abstraction
   layer, comparing results to the I-pipe version, thanks to having #1
   done.

Both the I-pipe and Dovetail maintain a version targeting kernel v5.4
LTS. We may use this common ground for comparing results, chasing
regressions during the initial phase of the port. Once we are confident
that the Dovetail side is in good shape, we may switch it to v5.10.

== Where do we start from?

In order to bootstrap this effort, I can resurrect the code I mentioned
in some other thread [1], which contains some groundwork for abstracting
the interrupt pipeline. Looking at the changes which have been pushed to
the Xenomai master branch since then, pulling them into this initial
work may be the more tractable option, in order to complete task #1.

In terms of documentation about Dovetail, [2] is the place to look for.

---

All the hard work which already took place on trying to get this port
done is certainly not lost, as it helped getting more people diving into
the innards of the dual kernel machinery. With more people sharing this
knowledge, we should be able to achieve this port quicker, and most
importantly, have a better chance keeping the pace with the Linux kernel
development in the long run.

I'm looking forward to discussing this proposal, other ideas, and
sharing the effort with anyone willing to contribute. The plan is to
start this work shortly, so please chime in early on if you intend to
discuss, help with this.

Thanks,

[1] https://lab.xenomai.org/xenomai-rpm.git/log/?h=wip/dovetail
[2] https://evlproject.org/dovetail/

-- 
Philippe.

Re: Xenomai 3.x over Dovetail

[Jan Kiszka]

On 19.11.20 13:25, Philippe Gerum wrote:
> 
> All,
> 
> After some recent discussion with Jan, I'm joining the fray in order to
> get Xenomai rebased on Dovetail, replacing the I-pipe, the in-kernel
> software layer which connects the real-time (Cobalt) core to the
> mainline Linux implementation. The main goal is to enable Xenomai 3.x
> for the most recent LTS kernel releases, such as the upcoming v5.10. A
> bit of context in the form of a Q&A:
> 
> Q: Why do we need the I-pipe to be replaced in the first place?
> A: Because Dovetail - as the successor to the I-pipe - addresses
>    important implementation and maintenance issues of the latter.
>    Maintaining two interfaces with identical goals concurrently any
>    further would make no sense, and would keep on diluting the scarce
>    manpower resources we have.
> 
> Q: Why can't we just port the I-pipe to v5.10, etc.?
> A: Because the aging design of the I-pipe would make this a very
>    difficult task, especially when confronted to massive code churn,
>    like the one which took place in the v5.8 cycle for x86. Although I'm
>    not claiming the upgrade process has become trivial, Dovetail is
>    certainly simpler to port to newer kernel releases than doing so for
>    the I-pipe might ever be. Dovetail tracks the kernel development tip,
>    runs v5.10-rc4 at the moment.
> 
> Q: What kind of I-pipe issues does Dovetail fix?
> A: Basically, a better integration with the mainline kernel
>    implementation, which eases the work of rebasing it on top of newer
>    kernel releases. It also provides crucial built-in capabilities such
>    as time and clock source management, real-time context switching and
>    fpu handling shared with the common kernel implementation, which
>    the real-time core does not have to care about anymore.
> 
> Q: Will switching to Dovetail have an impact on applications?
> A: No, the nitty-gritty details should live into the kernel and libcobalt,
>    without affecting the APIs.
> 
> Q: Will switching to Dovetail have an impact on the Xenomai ABI?
> A: Yes. Therefore the changes involved will be at core of Xenomai
>    3.2+. They won't be backported to Xenomai 3.1 or earlier.
> 
> Q: Which CPU architectures does Dovetail support today?
> A: aarch64, aarch32 (armv7 essentially), x86_64.
> 
> == Now, to the proposed broad plan for achieving this port:
> 
> 1- the ability to test the very same Cobalt code base on top of Dovetail
>    or the I-pipe alternatively may go a long way toward debugging the
>    port, particularly when it comes to spotting regressions. For
>    achieving this, we should insert some "interrupt pipeline"
>    abstraction layer into the Cobalt code. Depending on some build time
>    selector, the I-pipe or Dovetail interface would be used. Initially,
>    we could focus on having the I-pipe interface side working, which
>    should not be prone to regression since this task is basically about
>    moving code around, reorganizing the Cobalt code base.
> 
> 2- once the dust has settled on moving the code around, we need to
>    rework the timer management layer (xntimer) in order to switch the
>    internal date and delay representation from "clock ticks" (e.g. TSC
>    counts, or whatever unit some time hardware might use) to plain
>    nanoseconds, in order to align on the regular kernel representation
>    of time values (ktime_t, which Dovetail shares). Those changes will
>    impact libcobalt as well. Bonus: once this is done, applications may
>    safely get time stamps from primary mode using the fast vDSO
>    mechanism via clock_gettime() for instance. In addition, variation of
>    the CPU frequency (CPU_FREQ) will stop being a showstopper, since our
>    time stamps would not depend on the duration of a hardware tick
>    anymore.
> 
> 3- then, we may flesh out and test the Dovetail side of the abstraction
>    layer, comparing results to the I-pipe version, thanks to having #1
>    done.
> 
> Both the I-pipe and Dovetail maintain a version targeting kernel v5.4
> LTS. We may use this common ground for comparing results, chasing
> regressions during the initial phase of the port. Once we are confident
> that the Dovetail side is in good shape, we may switch it to v5.10.
> 
> == Where do we start from?
> 
> In order to bootstrap this effort, I can resurrect the code I mentioned
> in some other thread [1], which contains some groundwork for abstracting
> the interrupt pipeline. Looking at the changes which have been pushed to
> the Xenomai master branch since then, pulling them into this initial
> work may be the more tractable option, in order to complete task #1.

This is fine if we consider [1] similar to [3]: a platform to get
something building and then running. After that, a patch series against
master needs to be shaped, already to get the y2038 related refactorings
included (which are currently hacked away also in [3] but are now also WIP).

> 
> In terms of documentation about Dovetail, [2] is the place to look for.
> 
> ---
> 
> All the hard work which already took place on trying to get this port
> done is certainly not lost, as it helped getting more people diving into
> the innards of the dual kernel machinery. With more people sharing this
> knowledge, we should be able to achieve this port quicker, and most
> importantly, have a better chance keeping the pace with the Linux kernel
> development in the long run.
> 
> I'm looking forward to discussing this proposal, other ideas, and
> sharing the effort with anyone willing to contribute. The plan is to
> start this work shortly, so please chime in early on if you intend to
> discuss, help with this.
> 
> Thanks,
> 
> [1] https://lab.xenomai.org/xenomai-rpm.git/log/?h=wip/dovetail
> [2] https://evlproject.org/dovetail/
> 

Thanks for picking this up, your knowledge of both systems will be very
valuable!

Jan

[3] https://gitlab.denx.de/Xenomai/xenomai/-/commits/wip/dovetail

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

Re: Xenomai 3.x over Dovetail

[Greg Gallagher]

On Thu, Nov 19, 2020 at 7:58 AM Jan Kiszka via Xenomai <xenomai@xenomai.org>
wrote:

> On 19.11.20 13:25, Philippe Gerum wrote:
> >
> > All,
> >
> > After some recent discussion with Jan, I'm joining the fray in order to
> > get Xenomai rebased on Dovetail, replacing the I-pipe, the in-kernel
> > software layer which connects the real-time (Cobalt) core to the
> > mainline Linux implementation. The main goal is to enable Xenomai 3.x
> > for the most recent LTS kernel releases, such as the upcoming v5.10. A
> > bit of context in the form of a Q&A:
> >
> > Q: Why do we need the I-pipe to be replaced in the first place?
> > A: Because Dovetail - as the successor to the I-pipe - addresses
> >    important implementation and maintenance issues of the latter.
> >    Maintaining two interfaces with identical goals concurrently any
> >    further would make no sense, and would keep on diluting the scarce
> >    manpower resources we have.
> >
> > Q: Why can't we just port the I-pipe to v5.10, etc.?
> > A: Because the aging design of the I-pipe would make this a very
> >    difficult task, especially when confronted to massive code churn,
> >    like the one which took place in the v5.8 cycle for x86. Although I'm
> >    not claiming the upgrade process has become trivial, Dovetail is
> >    certainly simpler to port to newer kernel releases than doing so for
> >    the I-pipe might ever be. Dovetail tracks the kernel development tip,
> >    runs v5.10-rc4 at the moment.
> >
> > Q: What kind of I-pipe issues does Dovetail fix?
> > A: Basically, a better integration with the mainline kernel
> >    implementation, which eases the work of rebasing it on top of newer
> >    kernel releases. It also provides crucial built-in capabilities such
> >    as time and clock source management, real-time context switching and
> >    fpu handling shared with the common kernel implementation, which
> >    the real-time core does not have to care about anymore.
> >
> > Q: Will switching to Dovetail have an impact on applications?
> > A: No, the nitty-gritty details should live into the kernel and
> libcobalt,
> >    without affecting the APIs.
> >
> > Q: Will switching to Dovetail have an impact on the Xenomai ABI?
> > A: Yes. Therefore the changes involved will be at core of Xenomai
> >    3.2+. They won't be backported to Xenomai 3.1 or earlier.
> >
> > Q: Which CPU architectures does Dovetail support today?
> > A: aarch64, aarch32 (armv7 essentially), x86_64.
> >
> > == Now, to the proposed broad plan for achieving this port:
> >
> > 1- the ability to test the very same Cobalt code base on top of Dovetail
> >    or the I-pipe alternatively may go a long way toward debugging the
> >    port, particularly when it comes to spotting regressions. For
> >    achieving this, we should insert some "interrupt pipeline"
> >    abstraction layer into the Cobalt code. Depending on some build time
> >    selector, the I-pipe or Dovetail interface would be used. Initially,
> >    we could focus on having the I-pipe interface side working, which
> >    should not be prone to regression since this task is basically about
> >    moving code around, reorganizing the Cobalt code base.
> >
> > 2- once the dust has settled on moving the code around, we need to
> >    rework the timer management layer (xntimer) in order to switch the
> >    internal date and delay representation from "clock ticks" (e.g. TSC
> >    counts, or whatever unit some time hardware might use) to plain
> >    nanoseconds, in order to align on the regular kernel representation
> >    of time values (ktime_t, which Dovetail shares). Those changes will
> >    impact libcobalt as well. Bonus: once this is done, applications may
> >    safely get time stamps from primary mode using the fast vDSO
> >    mechanism via clock_gettime() for instance. In addition, variation of
> >    the CPU frequency (CPU_FREQ) will stop being a showstopper, since our
> >    time stamps would not depend on the duration of a hardware tick
> >    anymore.
> >
> > 3- then, we may flesh out and test the Dovetail side of the abstraction
> >    layer, comparing results to the I-pipe version, thanks to having #1
> >    done.
> >
> > Both the I-pipe and Dovetail maintain a version targeting kernel v5.4
> > LTS. We may use this common ground for comparing results, chasing
> > regressions during the initial phase of the port. Once we are confident
> > that the Dovetail side is in good shape, we may switch it to v5.10.
> >
> > == Where do we start from?
> >
> > In order to bootstrap this effort, I can resurrect the code I mentioned
> > in some other thread [1], which contains some groundwork for abstracting
> > the interrupt pipeline. Looking at the changes which have been pushed to
> > the Xenomai master branch since then, pulling them into this initial
> > work may be the more tractable option, in order to complete task #1.
>
> This is fine if we consider [1] similar to [3]: a platform to get
> something building and then running. After that, a patch series against
> master needs to be shaped, already to get the y2038 related refactorings
> included (which are currently hacked away also in [3] but are now also
> WIP).
>
> >
> > In terms of documentation about Dovetail, [2] is the place to look for.
> >
> > ---
> >
> > All the hard work which already took place on trying to get this port
> > done is certainly not lost, as it helped getting more people diving into
> > the innards of the dual kernel machinery. With more people sharing this
> > knowledge, we should be able to achieve this port quicker, and most
> > importantly, have a better chance keeping the pace with the Linux kernel
> > development in the long run.
> >
> > I'm looking forward to discussing this proposal, other ideas, and
> > sharing the effort with anyone willing to contribute. The plan is to
> > start this work shortly, so please chime in early on if you intend to
> > discuss, help with this.
> >
> > Thanks,
> >
> > [1] https://lab.xenomai.org/xenomai-rpm.git/log/?h=wip/dovetail
> > [2] https://evlproject.org/dovetail/
> >
>
> Thanks for picking this up, your knowledge of both systems will be very
> valuable!
>
> Jan
>
> [3] https://gitlab.denx.de/Xenomai/xenomai/-/commits/wip/dovetail
>
> --
> Siemens AG, T RDA IOT
> Corporate Competence Center Embedded Linux
>

Hi,
   I have the arm/arm64 5.4 Ipipe ported, my plan is to continue testing
and push the branches up on the weekend.

  I’m available to help with the port.   Tasks I can take on would be
dependent on how much time I have available but definitely willing to help
out.

Thanks

Greg

>
>

Re: Xenomai 3.x over Dovetail

[Philippe Gerum]

Jan Kiszka <jan.kiszka@siemens.com> writes:

> On 19.11.20 13:25, Philippe Gerum wrote:
>> 
>> All,
>> 
>> After some recent discussion with Jan, I'm joining the fray in order to
>> get Xenomai rebased on Dovetail, replacing the I-pipe, the in-kernel
>> software layer which connects the real-time (Cobalt) core to the
>> mainline Linux implementation. The main goal is to enable Xenomai 3.x
>> for the most recent LTS kernel releases, such as the upcoming v5.10. A
>> bit of context in the form of a Q&A:
>> 
>> Q: Why do we need the I-pipe to be replaced in the first place?
>> A: Because Dovetail - as the successor to the I-pipe - addresses
>>    important implementation and maintenance issues of the latter.
>>    Maintaining two interfaces with identical goals concurrently any
>>    further would make no sense, and would keep on diluting the scarce
>>    manpower resources we have.
>> 
>> Q: Why can't we just port the I-pipe to v5.10, etc.?
>> A: Because the aging design of the I-pipe would make this a very
>>    difficult task, especially when confronted to massive code churn,
>>    like the one which took place in the v5.8 cycle for x86. Although I'm
>>    not claiming the upgrade process has become trivial, Dovetail is
>>    certainly simpler to port to newer kernel releases than doing so for
>>    the I-pipe might ever be. Dovetail tracks the kernel development tip,
>>    runs v5.10-rc4 at the moment.
>> 
>> Q: What kind of I-pipe issues does Dovetail fix?
>> A: Basically, a better integration with the mainline kernel
>>    implementation, which eases the work of rebasing it on top of newer
>>    kernel releases. It also provides crucial built-in capabilities such
>>    as time and clock source management, real-time context switching and
>>    fpu handling shared with the common kernel implementation, which
>>    the real-time core does not have to care about anymore.
>> 
>> Q: Will switching to Dovetail have an impact on applications?
>> A: No, the nitty-gritty details should live into the kernel and libcobalt,
>>    without affecting the APIs.
>> 
>> Q: Will switching to Dovetail have an impact on the Xenomai ABI?
>> A: Yes. Therefore the changes involved will be at core of Xenomai
>>    3.2+. They won't be backported to Xenomai 3.1 or earlier.
>> 
>> Q: Which CPU architectures does Dovetail support today?
>> A: aarch64, aarch32 (armv7 essentially), x86_64.
>> 
>> == Now, to the proposed broad plan for achieving this port:
>> 
>> 1- the ability to test the very same Cobalt code base on top of Dovetail
>>    or the I-pipe alternatively may go a long way toward debugging the
>>    port, particularly when it comes to spotting regressions. For
>>    achieving this, we should insert some "interrupt pipeline"
>>    abstraction layer into the Cobalt code. Depending on some build time
>>    selector, the I-pipe or Dovetail interface would be used. Initially,
>>    we could focus on having the I-pipe interface side working, which
>>    should not be prone to regression since this task is basically about
>>    moving code around, reorganizing the Cobalt code base.
>> 
>> 2- once the dust has settled on moving the code around, we need to
>>    rework the timer management layer (xntimer) in order to switch the
>>    internal date and delay representation from "clock ticks" (e.g. TSC
>>    counts, or whatever unit some time hardware might use) to plain
>>    nanoseconds, in order to align on the regular kernel representation
>>    of time values (ktime_t, which Dovetail shares). Those changes will
>>    impact libcobalt as well. Bonus: once this is done, applications may
>>    safely get time stamps from primary mode using the fast vDSO
>>    mechanism via clock_gettime() for instance. In addition, variation of
>>    the CPU frequency (CPU_FREQ) will stop being a showstopper, since our
>>    time stamps would not depend on the duration of a hardware tick
>>    anymore.
>> 
>> 3- then, we may flesh out and test the Dovetail side of the abstraction
>>    layer, comparing results to the I-pipe version, thanks to having #1
>>    done.
>> 
>> Both the I-pipe and Dovetail maintain a version targeting kernel v5.4
>> LTS. We may use this common ground for comparing results, chasing
>> regressions during the initial phase of the port. Once we are confident
>> that the Dovetail side is in good shape, we may switch it to v5.10.
>> 
>> == Where do we start from?
>> 
>> In order to bootstrap this effort, I can resurrect the code I mentioned
>> in some other thread [1], which contains some groundwork for abstracting
>> the interrupt pipeline. Looking at the changes which have been pushed to
>> the Xenomai master branch since then, pulling them into this initial
>> work may be the more tractable option, in order to complete task #1.
>
> This is fine if we consider [1] similar to [3]: a platform to get
> something building and then running. After that, a patch series against
> master needs to be shaped, already to get the y2038 related refactorings
> included (which are currently hacked away also in [3] but are now also WIP).
>

Yes. The original effort was based on #3f1ee69208b0 from master,
somewhere between 3.1-rc1 and -rc2. Gradually picking anything which has
landed on top of this over time should properly reconcile wip/dovetail
with master.

-- 
Philippe.

Re: Xenomai 3.x over Dovetail

[Philippe Gerum]

Greg Gallagher <greg@embeddedgreg.com> writes:

> On Thu, Nov 19, 2020 at 7:58 AM Jan Kiszka via Xenomai <xenomai@xenomai.org>
> wrote:
>
>> On 19.11.20 13:25, Philippe Gerum wrote:
>> >
>> > All,
>> >
>> > After some recent discussion with Jan, I'm joining the fray in order to
>> > get Xenomai rebased on Dovetail, replacing the I-pipe, the in-kernel
>> > software layer which connects the real-time (Cobalt) core to the
>> > mainline Linux implementation. The main goal is to enable Xenomai 3.x
>> > for the most recent LTS kernel releases, such as the upcoming v5.10. A
>> > bit of context in the form of a Q&A:
>> >
>> > Q: Why do we need the I-pipe to be replaced in the first place?
>> > A: Because Dovetail - as the successor to the I-pipe - addresses
>> >    important implementation and maintenance issues of the latter.
>> >    Maintaining two interfaces with identical goals concurrently any
>> >    further would make no sense, and would keep on diluting the scarce
>> >    manpower resources we have.
>> >
>> > Q: Why can't we just port the I-pipe to v5.10, etc.?
>> > A: Because the aging design of the I-pipe would make this a very
>> >    difficult task, especially when confronted to massive code churn,
>> >    like the one which took place in the v5.8 cycle for x86. Although I'm
>> >    not claiming the upgrade process has become trivial, Dovetail is
>> >    certainly simpler to port to newer kernel releases than doing so for
>> >    the I-pipe might ever be. Dovetail tracks the kernel development tip,
>> >    runs v5.10-rc4 at the moment.
>> >
>> > Q: What kind of I-pipe issues does Dovetail fix?
>> > A: Basically, a better integration with the mainline kernel
>> >    implementation, which eases the work of rebasing it on top of newer
>> >    kernel releases. It also provides crucial built-in capabilities such
>> >    as time and clock source management, real-time context switching and
>> >    fpu handling shared with the common kernel implementation, which
>> >    the real-time core does not have to care about anymore.
>> >
>> > Q: Will switching to Dovetail have an impact on applications?
>> > A: No, the nitty-gritty details should live into the kernel and
>> libcobalt,
>> >    without affecting the APIs.
>> >
>> > Q: Will switching to Dovetail have an impact on the Xenomai ABI?
>> > A: Yes. Therefore the changes involved will be at core of Xenomai
>> >    3.2+. They won't be backported to Xenomai 3.1 or earlier.
>> >
>> > Q: Which CPU architectures does Dovetail support today?
>> > A: aarch64, aarch32 (armv7 essentially), x86_64.
>> >
>> > == Now, to the proposed broad plan for achieving this port:
>> >
>> > 1- the ability to test the very same Cobalt code base on top of Dovetail
>> >    or the I-pipe alternatively may go a long way toward debugging the
>> >    port, particularly when it comes to spotting regressions. For
>> >    achieving this, we should insert some "interrupt pipeline"
>> >    abstraction layer into the Cobalt code. Depending on some build time
>> >    selector, the I-pipe or Dovetail interface would be used. Initially,
>> >    we could focus on having the I-pipe interface side working, which
>> >    should not be prone to regression since this task is basically about
>> >    moving code around, reorganizing the Cobalt code base.
>> >
>> > 2- once the dust has settled on moving the code around, we need to
>> >    rework the timer management layer (xntimer) in order to switch the
>> >    internal date and delay representation from "clock ticks" (e.g. TSC
>> >    counts, or whatever unit some time hardware might use) to plain
>> >    nanoseconds, in order to align on the regular kernel representation
>> >    of time values (ktime_t, which Dovetail shares). Those changes will
>> >    impact libcobalt as well. Bonus: once this is done, applications may
>> >    safely get time stamps from primary mode using the fast vDSO
>> >    mechanism via clock_gettime() for instance. In addition, variation of
>> >    the CPU frequency (CPU_FREQ) will stop being a showstopper, since our
>> >    time stamps would not depend on the duration of a hardware tick
>> >    anymore.
>> >
>> > 3- then, we may flesh out and test the Dovetail side of the abstraction
>> >    layer, comparing results to the I-pipe version, thanks to having #1
>> >    done.
>> >
>> > Both the I-pipe and Dovetail maintain a version targeting kernel v5.4
>> > LTS. We may use this common ground for comparing results, chasing
>> > regressions during the initial phase of the port. Once we are confident
>> > that the Dovetail side is in good shape, we may switch it to v5.10.
>> >
>> > == Where do we start from?
>> >
>> > In order to bootstrap this effort, I can resurrect the code I mentioned
>> > in some other thread [1], which contains some groundwork for abstracting
>> > the interrupt pipeline. Looking at the changes which have been pushed to
>> > the Xenomai master branch since then, pulling them into this initial
>> > work may be the more tractable option, in order to complete task #1.
>>
>> This is fine if we consider [1] similar to [3]: a platform to get
>> something building and then running. After that, a patch series against
>> master needs to be shaped, already to get the y2038 related refactorings
>> included (which are currently hacked away also in [3] but are now also
>> WIP).
>>
>> >
>> > In terms of documentation about Dovetail, [2] is the place to look for.
>> >
>> > ---
>> >
>> > All the hard work which already took place on trying to get this port
>> > done is certainly not lost, as it helped getting more people diving into
>> > the innards of the dual kernel machinery. With more people sharing this
>> > knowledge, we should be able to achieve this port quicker, and most
>> > importantly, have a better chance keeping the pace with the Linux kernel
>> > development in the long run.
>> >
>> > I'm looking forward to discussing this proposal, other ideas, and
>> > sharing the effort with anyone willing to contribute. The plan is to
>> > start this work shortly, so please chime in early on if you intend to
>> > discuss, help with this.
>> >
>> > Thanks,
>> >
>> > [1] https://lab.xenomai.org/xenomai-rpm.git/log/?h=wip/dovetail
>> > [2] https://evlproject.org/dovetail/
>> >
>>
>> Thanks for picking this up, your knowledge of both systems will be very
>> valuable!
>>
>> Jan
>>
>> [3] https://gitlab.denx.de/Xenomai/xenomai/-/commits/wip/dovetail
>>
>> --
>> Siemens AG, T RDA IOT
>> Corporate Competence Center Embedded Linux
>>
>
> Hi,
>    I have the arm/arm64 5.4 Ipipe ported, my plan is to continue testing
> and push the branches up on the weekend.
>
>   I’m available to help with the port.   Tasks I can take on would be
> dependent on how much time I have available but definitely willing to help
> out.
>

Ack, thanks. The list of SoCs Dovetail is known to run on is published
at [1]. We will need a broader coverage for testing.

[1] https://evlproject.org/ports/

-- 
Philippe.