New Repository Request

Brad Bishop bradleyb at
Wed Sep 19 08:37:00 AEST 2018

> On Sep 18, 2018, at 11:47 AM, Patrick Venture <venture at> wrote:
>> On Fri, Sep 14, 2018 at 6:00 AM Brad Bishop <bradleyb at> 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).

> 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.

More information about the openbmc mailing list