Fwd: Re: The problem with GIT. This is a bug of GIT itself

Philippe Gerum rpm at xenomai.org
Wed Feb 19 19:09:59 CET 2020


Hi,

On 2/19/20 9:20 AM, leo via Evl wrote:
> 
> Well.
> 
> Currently, I am adapting the OpenSUSE rpm package build system.
> https://github.com/openSUSE/kernel-source
> The idea came from there. All patches there are spread out in different
> folders,
> and the order of their application is contained in a single file
> series.conf.
> In this case, no numbered prefixes are required, as 'git format-patch'
> does.
> In one folder there are 'dovetail' patches, in the other only 'evl'
> patches.
> Their names do not change with each step. You can easily see the history
> of an individual patch. And most importantly, this process is easy to
> automate.
> You don't need a lot of extra work. Just run the script and commit.

Originally, i.e. a few years ago, Dovetail was only composed of 15-20
patches for supporting the  ARM architecture, each of them introducing
the  "out-of-band" execution logic in a specific part of the kernel.
First, there were a few patches adding generic features such as
raw_printk, vDSO-visible MMIO clock sources and so on, followed by  the
generic code such as the IRQ pipeline core and  Dovetail's so-called
"alternate scheduling"  support. The rest of the patch series would be
architecture-specific:

- a patch completing the IRQ pipeline core for the ARM arch.
- a patch completing the alternate scheduling support for the ARM arch.
- a patch introducing the out-of-band handling of system calls
- a patch providing support for routine CPU exceptions to a companion
core like EVL
- some patches fixing up the irqchip controllers for dealing with
pipelined IRQs.
- some patches fixing up the clock source drivers for dealing with tick
proxying (i.e. controlling the tick device from the companion core).

This original patch series obviously grew over time, with bug fixes and
architecture-specific bits for arm64 and x86, although the feature set
Dovetail adds to the kernel remained fairly stable over time.

I plan to open a few more branches, folding all of these fixes where
they should belong into the original feature-oriented series of commits,
and to split the development tip and the latest stable code. That would
give something along these lines:

dovetail/master and evl/master: current "stable" (as in "not in some
erratic state of flux") branches. If created today, they would track
mainline v5.5, with the dovetail series only and the full EVL stack on
top respectively.

evl/next: the tip of the development when still in mainline's -rc cycle,
containing a mix of the latest dovetail and EVL-specific changes. At
some point, evl/next would be used to create dovetail/master and
evl/master when the final mainline release is out. Today, that one would
track 5.6-rc2.

dovetail/squashed would track dovetail/master hopefully, or at least a
stable dovetail state for a recent kernel, folding its content so as to
present a clean (and limited) stack of patches on top of mainline.

> I think that if the build process is brought closer to the ideology of
> such mass
> linux distributions as opensuse and ubuntu
> the number of subscribers to the project will increase significantly.
I agree on the benefit of making the work of distributions easier.

This said, I doubt the number of subscribers would express anything
about the success of any project. A significant proportion of
subscribers who do participate to discussions would do though, at least
in my mind.

Maybe a mailing list has become an obsolete medium over time. For anyone
interested, I created a RIOT channel [1] for more interactive
communication, which I'm usually connected to.

[1] https://riot.im/app/#/room/#evlproject:matrix.org

-- 
Philippe.



More information about the Evl mailing list