When building OpenBMC . . . ?

[Ed Tanous]

On Tue, Sep 1, 2020 at 5:26 AM Patrick Williams <patrick at stwcx.xyz> wrote:
>
> On Sun, Aug 30, 2020 at 10:02:41PM +0000, Bruce Mitchell wrote:
> > When selecting Target hardware https://github.com/openbmc/openbmc#3-target-your-hardware
> > to build for the is a tiogapass, now if I add a meta-phoenix/meta-tiogapass/conf  how does
> >       source setup tiogapass build
> > know which tiogapass to build?
>
> https://github.com/openbmc/openbmc/blob/master/setup#L34
>
> The setup script just does a wildcard, which means you'll get the
> alphabetically ordered machine.  In this case, you should get the
> meta-facebook one selected before the meta-phoenix (supposing they both
> exist).
>
> > Or am I not supposed to choose a name (i.e. tiogapass in this example) that is already in the list
> > when I need to create a new meta-phoenix/meta-<machine>/conf?
>
> The overwhelming preference seems to be to not make another
> configuration with the same machine, and as one of the maintainers of
> meta-facebook, I agree in this case.  But, this answer doesn't solve
> your underlying question.
>
> I suspect you're going to make two kinds of changes:
>   1. Features you want to enable on Tiogapass that Facebook isn't
>      interested in.  (I would cover bmcweb 'branding' changes here
>      also).

bmcweb branding is a machine independent feature.  At some point we
might have the webui feature enable/disable things again, and who
knows, maybe we need machine specific branding, but I want to avoid it
wherever possible.

>   2. Fixes and configuration due to features we haven't enabled yet or
>      fully vetted.
>
> #2 should go into either meta-facebook (or the underlying code
> repository where the fix is needed).  These will be common for any

+1

Could we also make the statement that as a project, we will enable
every platform feature we are able to for every platform by default,
and if a company wants to specifically disable some features for their
use because they haven't vetted them, they should do that in a
specific distro?  Said another way, the "default" for every machine
should be every feature enabled, as that's what helps users and
developers the most.

>
> #1 should go into meta-phoenix.  You're likely the first one doing this,
> so we may need some experimentation on the best option.  I have two
> ideas (there are probably others):
>
>   * Make an alternative tiogapass variant, like tiogapass-phoenix, which
>     ends up including all the common tiogapass code from meta-facebook.
>
>   * Create a new distro type for phoenix, which enhances the underlying
>     openbmc distribution with your own branding tweaks.  You'd still
>     build meta-facebook/tiogapass but with a different distro flavor.

This one would be my vote between the two, and I think there's
precedent with other companies doing similar things.  Isn't this the
way yocto recommends?

>
> I believe IBM has experiemented with both of these approaches for
> witherspoon (see witherspoon-tacoma and
> meta-ibm/conf/distro/openbmc-witherspoon.conf) and might have some
> insight into what has worked well for them.
>
> I'm more than willing to work with you and your team to help refactor
> meta-facebook/tiogapass in a way that makes it more condusive to what
> your team is interested in doing.  I suspect we'll need to create some
> additional bitbake '.inc' files and move some of the content we have in
> '.conf' to '.inc'.  Catch me here or on IRC as needed.
>
> --
> Patrick Williams