Re: [PATCH dovetail v3 0/8] riscv: Add Dovetail support

[Philippe Gerum <philippe.gerum@gmail.com>]

Hi Tobias,

Tobias Schaffner <tobias.schaffner@siemens.com> writes:

> Hi Philippe,
>
> The EVL testsuite is running successfully on QEMU with this set of patches.
>

Nice work.

> I’d like to ask how we should proceed from here.
>
> If possible, I’d like to merge the RISC-V components for
> xenomai-images so that we can set up an initial testing pipeline. To
> do that, we’ll need a development branch that integrates the Dovetail
> and EVL components, which can be referenced.
>
> My private testing branch[1] is currently based on v6.12-evl1-rebase,
> but I’m happy to port it to whichever version you’d prefer to continue
> with.
>

You now have maintainer access to the
linux-dovetail.git/wip/dovetail-riscv and linux-evl.git/wip/evl-riscv
branches. You should be able to maintain the Dovetail and EVL core ports
from those separate trees. Both branches should be considered as
rebasable. Those kernel trees contain the riscv bits I once harvested on
the mailing list some time ago, so by no mean up to date. You can
definitely replace them at will.

You also have maintainer access to the libevl.git/wip/libevl-riscv branch
(rebasable too), which I just forked off the -next branch.  I'll pull
from the former branch when deemed ready. Please keep in sync with
-next, not master.

linux-evl/wip/evl-riscv and libevl/wip/libevl-riscv can be the source
trees for xenomai-images at the moment, until merged.

The Dovetail kernel tree should not contain any EVL-specific bit so that
other real-time cores (e.g. x3 Cobalt) can use it seamlessly as well,
the EVL tree should include the Dovetail tree plus the EVL core with
riscv support.

The Dovetail patch set should introduce riscv support piecemeal, in a
way which allows us to bisect code when chasing regressions by enabling
features incrementally, from mere interrupt pipelining to alternate
scheduling of oob threads, along with oob networking, oob device support
(gpio, clocksources, timers). Of course, as development goes on, we end
up with individual fixes stacked on top of this ideal series of
commits. From time to time, these fixes are squashed into the commits
forming the fundamental series I just mentioned.

e.g. looking at rebase/v6.17-dovetail, the fundamental series adding
Dovetail support piecemeal goes from 12e0fbdff1d45 to
c09b64e1767a2. Commits on top of this range are fixes to this series,
which we may squash at some point, when forward porting to some upcoming
kernel release (this normally happens during the upstream -rc cycle).

As you know, the EVL tree for a newer kernel release is obtained from
forking off the matching Dovetail tree, forward porting the EVL bits
from the latest release. Pretty straightforward. Here again, we may have
Dovetail fixes landing on top, and EVL fixes as well. The latter are
never squashed though. Any merge-related change to the EVL bits most
often appears explicitly in an individual commit, because there are very
few places for merge conflicts with upstream changes in the EVL code
base, so we are usually able to merge seamlessly, we have to compile and
run it for finding issues in most cases.

Eventually, the plan is to merge wip/dovetail-riscv and wip/evl-riscv
into the linux-dovetail and linux-evl trees when ready. A working
initial port of EVL to some riscv hardware would indicate that such port
is ready for inclusion.

Basing the initial riscv port on v6.12.y-cip would benefit people who
need an SLTS kernel. However, this would also double the initial
maintenance work on your end, since we are going to need a port to v6.18
which is brewing here. What's your take on this?

-- 
Philippe.