moving meta-{openpower, x86, arm} content to meta-phosphor

[Ed Tanous]

On Thu, Aug 20, 2020 at 6:18 AM Brad Bishop <bradleyb at fuzziesquirrel.com> wrote:
>
> Fellow OpenBMCers
>
> Over time, I would like to do away with the processor arch layers e.g.
>
> meta-openpower, meta-arm, meta-x86.
>
> In hindsight meta-arm and meta-x86 might not have made much sense and
> should have been something like meta-x86-intel and meta-x86-amd perhaps
> - this is confirmed by the fact that there isn't any content in meta-
> x86.
>
> I propose the content simply go in meta-phosphor, and that we frame our
> thinking of meta-phosphor and OpenBMC as a project that supports any and
> all host processor architectures (as well as devices that aren't servers
> at all).  This results in several positive things:
>
> - Increased developer/maintainer awareness/cross pollination of other
> usage patterns (community building).
> - Differences are obvious, highlighting areas for improvement in the
> project.
> - Build time, cross arch incompatibilities become obvious (e.g. building
> images that support both Intel and AMD processors for example).
> - Improved time to understanding for newcomers - everything is one
> place.
> - Reduced (granted a small amount) layer configuration complexity for
> end users.

Sounds pretty reasonable.  I wonder if we should go even further, and
not even model the host processor differences in meta layers at all.
We would simply enable certain features/packages for certain machines.
That makes sure that we aren't turning on features for machines that
haven't been tested yet, but doesn't require a full move over if
someone wants to enable a new processor type on a system that didn't
already support it.  It also hopefully means that the "default" would
be to start with an existing application, and simply add support for a
given processor/architecture/feature rather than starting over from
scratch more of the time.
The other thing I would add is that it (hopefully) leads to more reuse
between configurations.  Things like "peci-pcie" might one day become
"Pcie-inventory", and simply support all processor inventory types
that it can.

>
> I'm not aware of any benefits to factoring things out into the different
> layers like we have today - if you are aware of something, please share.
>
> Getting more detailed, how would this look?  This series is an example:
>
> https://gerrit.openbmc-project.xyz/35759
>
> For projects that are truly host processor specific e.g. peci or occ
> support, we already have a recipes-x86 folder:

It should be noted, I wrote the above comment about peci-pcie before I
read this part.  Hah.

>
> https://github.com/openbmc/meta-phosphor/tree/master/recipes-x86
>
> I propose we allow the creation of additional folders using this
> convention e.g.
>
> - recipes-power
> - recipes-x86-amd (we might want to look at renaming recipes-x86 to
> recipes-x86-intel)

I no longer have a dog in this fight, but as a developer the above
sounds reasonable.

>
> Or even better IMO, we co-mingle these recipes as well based on the
> abstract function they provide for some of the same reasons I would like
> to move to a single layer - increased awareness of what your community
> peers are up to.
>

I should really learn to read the whole document before writing
comments :)  Sounds like we had similar thoughts.  +1