New Repository Request

Patrick Venture venture at google.com
Wed Sep 19 01:47:16 AEST 2018


On Fri, Sep 14, 2018 at 6:00 AM Brad Bishop <bradleyb at fuzziesquirrel.com> wrote:
>
>
> > On Sep 13, 2018, at 1:55 PM, Patrick Venture <venture at google.com> wrote:
> >
> > Brad,
> >
> > I'd like to set up a new repository in openbmc to store a google oem
> > ipmi library I'd like to share with everybody.  It allows grabbing
> > ethernet device statistics over IPMI.
> >
> > I have no problem registering it under the OpenBMC OEN (and the google
> > one) since OEM registration supports that -- then it could be
> > phosphor-ipmi-ethstats.
> >
> > I really would like to share the code -- but I would be ok with it
> > being in a google-specific repository, such as google-ipmi-ethstats --
> > If so, I'll put the recipe in meta-google.
> >
> > I know we've talked about this before, and it really feels like six in
> > one hand on this —
>
> As far as where the code is hosted I’m good one way or the other.
> Will wait a couple days for objections and create openbmc/phosphor-ipmi-ethstats.

Please go ahead and create openbmc/phosphor-ipmi-ethstats unless you'd
rather create openbmc/google-ipmi-ethstats.  I'm ok with doing the
extra bit of wiring it up to OpenBMC, which would really be the
difference.  But given your concern below -- I'm willing to own it
under google until the implications are worked out.

>
> It might be good to have a conversation around how we handle the OpenBMC OEN
> though.  Putting things there would seem to have lasting impact for everyone
> using OpenBMC and we don’t have any process in place for that.

That's correct.  So, right now, the extra handlers aren't enabled to
be included in the image by default.  Someone would need to select
them, which I like.  As that's an opt-in behavior.  And if there's
interplay between the things, they can explicitly indicate that in
bitbake and in a README.

Consider, that each company may want to share their handlers - which I
think is great.  It enables vendors, if nothing else, and encourages
them to switch to OpenBMC to sell hardware to IBM, Google, etc.  I
also prefer the opt-in model for features, which this fits (repeated
point).

If we share them openly and register the numbers in
phosphor-host-ipmid, we can better enable a vendor or someone to say,
I want to support _all_ the environments, and just flip all the
switches.  To this end, I'm considering re-submitting the oemgoog
header to phosphor-host-ipmid, but by flagging its inclusion via a
build-time flag.  So, one could say, build a clean phosphor-host-ipmid
by building the default, but if they --enable-google or --enable-intel
maybe they get the extra headers included under something like
host-ipmid/oem/oemgoogle.hpp (need to send patch to maintainers for
review sometime today).

>
> >
> > Thanks,
> > Patrick


More information about the openbmc mailing list