When building OpenBMC . . . ?

[Bruce Mitchell]

Thank you Ed!  Your suggest of what Yocto recommends is good and we will investigate further.

> -----Original Message-----
> From: Ed Tanous [mailto:ed at tanous.net]
> Sent: Tuesday, September 1, 2020 09:10
> To: Patrick Williams
> Cc: Bruce Mitchell; openbmc at lists.ozlabs.org
> Subject: Re: When building OpenBMC . . . ?
> 
> 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