interest in a minimal image recipe

Ed Tanous ed at tanous.net
Thu Sep 24 05:46:16 AEST 2020


On Tue, Sep 22, 2020 at 1:40 PM Vijay Khemka <vijaykhemka at fb.com> wrote:
>
>
>
> On 9/21/20, 10:57 AM, "openbmc on behalf of Brad Bishop" <openbmc-bounces+vijaykhemka=fb.com at lists.ozlabs.org on behalf of bradleyb at fuzziesquirrel.com> wrote:
>
>     On Mon, Sep 21, 2020 at 08:53:26AM -0700, Ed Tanous wrote:
>     >On Mon, Sep 21, 2020 at 5:55 AM Brad Bishop <bradleyb at fuzziesquirrel.com> wrote:
>     >>
>     >> In what way does EM require intel-ipmi-oem?  I am using EM without
>     >> intel-ipmi-oem without (I thought anyway) issue.
>     >
>     >You're running Entity Manager, without intel-ipmi-oem, and you can run
>     >a successful "ipmitool sensor list" or "ipmitool fru print" command,
>     >and have it return the entity manager/dbus-sensors/FruDevice results?
>
>     Ah, now I understand.  No, I can't do that.  But I don't need to because
>     the default IPMI handler implementations in phosphor-host-ipmid work for
>     me (the YAML based ones), and those don't need entity-manager.  I'm
>     using entity-manager for other reasons.
>
>     As an aside - I think a majority are using the intel-ipmi-oem handlers
>     now so I'd support moving those into phosphor-host-ipmid and using them
>     as the defaults.  But that must not be easy, otherwise Intel would have
>     just done that rather than forking the handlers in intel-ipmi-oem in the
>     first place.
> I support moving many standard commands from intel-ipmi-oem to
> phosphor-host-ipmid.  Entity manager is required only for fru and
> sensor SDR ipmi command but there are many other commands
> which are useful and can be moved.
>
>     But in any case, intel-ipmi-oem requires entity-manager, not the other
>     way around right?  The "feature" being selected here is the Intel IPMI
>     handler forks, and that would simply depend on entity-manager.  A
>     strawman:
>
>     obmc-phosphor-image.bbclass:
>     FEATURE_PACKAGES_intel-ipmi-handler-forks = "packagegroup-intel-ipmi-handler-forks"
>
>     packagegroup-obmc-apps.bb:
>     RDEPENDS_packagegroup-obmc-apps-intel-ipmi-handler-forks = "intel-ipmi-oem"
>
>     intel-ipmi-oem.bb:
>     RDEPENDS_${PN} = "entity-manager"
>
>     One prerequisite to this is that the intel-ipmi-oem recipe would need to
>     move to meta-phosphor.  Perhaps its time for the repo to be renamed into
>     something else.
> We may have to split and look for what we need from intel-ipmi-oem. There
> are lots of intel oem specific command in this which are not useful for
> many other platforms and are overridden by their own xx-ipmi-oem.
>
> We should simply port standard ipmi command from intel-ipmi-oem to
> Phosphor-host-ipmid.

+1

>
>     >In my understanding, this shouldn't work, and we've had many reports
>     >of "I enabled entity manager, and my sensors don't show up in IPMI".
>     I don't think the answer to "how do I enable IPMI sensors" was ever
>     "enable entity manager" was it?  To enable IPMI, you have always needed
>     to enable either the original YAML based handlers or the intel-ipmi-oem
>     forks.
>
> We should fix this in host-ipmid, as all sensors are added to standard dbus
> Interface and if it is not discoverable by mapper or object manager then we
> should fix it so that an SDR can be built independent of sensor implementation.
>

I agree with all the above.  Do you think you could get the patches
pushed to start this discussion in gerrit?


More information about the openbmc mailing list