New Repository Request

[Patrick Venture]

On Tue, Sep 18, 2018 at 3:37 PM Brad Bishop <bradleyb at fuzziesquirrel.com> wrote:
>
> > On Sep 18, 2018, at 11:47 AM, Patrick Venture <venture at google.com> wrote:
> >
> >> On Fri, Sep 14, 2018 at 6:00 AM Brad Bishop <bradleyb at fuzziesquirrel.com> wrote:
> >>
> >> 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.
>
> I’m more concerned with the number the end user types in when they run ipmitool.
>
> > Someone would need to select them, which I like.  As that's an opt-in behavior.
>
> I’m not understanding the relationship between opt-in and the OEN number.  In my
> mind there isn’t one.  Isn’t the question instead: for a given OEM extension, is
> the OEN number OpenBMCs or foo-corps (irrespective of whether or not a system
> integrator opts-in or opts-out of including a specific extension in their image).

So the OEN just existing in the source doesn't impact anything.  It
only allows some piece of code to use that number.  And any handlers
that register in that space only exist on a platform if the platform
owner selects them to.  If a functionality isn't there, the ipmitool
users just get an unsupported style error indicative of any command
not recognized -- which is what happens now with the commands that
aren't implemented in the core.

I think the general goal with companies exposing their IPMI special
handlers is to share compliance with each other to some extent, which
is less about the end user and more about infrastructure layers.  I
don't imagine many people playing around with ipmi will care or build
images that enable these extra commands, but companies may.

I'm not sure if that was your concern.

>
> > 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
>
> I feel like there has to be a way to do the same thing without the need for
> —-enable-xyzcorp switches.  I wouldn’t want to maintain that.

Yeah, I went down that road a bit and it doesn't stay pretty long.
But really it's unnecessary to gate whether a header file exists when
that header file only provides a list of numbers.