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

Supreeth Venkatesh supreeth.venkatesh at
Fri Aug 21 01:20:54 AEST 2020

On 8/20/20 8:15 AM, Brad Bishop wrote:
> [CAUTION: External Email]
> Fellow OpenBMCers
Hi Brad,
> 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.
> 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:
> For projects that are truly host processor specific e.g. peci or occ
> support, we already have a recipes-x86 folder:
PECI is specific to Intel host x86 Architecture.
APML is used for AMD host x86 architecture.
> 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)
Yes. It would be apt to rename recipes-x86 to recipes-x86-intel and recipes-x86-amd because of differences noted above for now.

> 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.
This is interesting, I like this approach as I hope this will lead to more collaboration within the community.
> Please share your thoughts on the matter.
> thx - brad

More information about the openbmc mailing list