All of lore.kernel.org
 help / color / mirror / Atom feed
From: Ed Tanous <ed@tanous.net>
To: Vijay Khemka <vijaykhemka@fb.com>
Cc: OpenBMC Maillist <openbmc@lists.ozlabs.org>,
	Brad Bishop <bradleyb@fuzziesquirrel.com>
Subject: Re: interest in a minimal image recipe
Date: Wed, 23 Sep 2020 12:46:16 -0700	[thread overview]
Message-ID: <CACWQX82ARgwPo1LCWF3fYZtzXtj4p=ty43xN21qX9GOZdzLKhQ@mail.gmail.com> (raw)
In-Reply-To: <DB1605BB-81F4-4297-9BC0-BC1B054BAAEB@fb.com>

On Tue, Sep 22, 2020 at 1:40 PM Vijay Khemka <vijaykhemka@fb.com> wrote:
>
>
>
> On 9/21/20, 10:57 AM, "openbmc on behalf of Brad Bishop" <openbmc-bounces+vijaykhemka=fb.com@lists.ozlabs.org on behalf of bradleyb@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@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?

  reply	other threads:[~2020-09-23 19:47 UTC|newest]

Thread overview: 26+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-09-15 20:28 interest in a minimal image recipe Brad Bishop
2020-09-15 20:58 ` Khetan, Sharad
2020-09-15 21:27   ` Sriram Ramkrishna
2020-09-17 20:10 ` Brad Bishop
2020-09-17 21:02   ` Ed Tanous
2020-09-21 13:21     ` Andrew Geissler
2020-09-17 20:56 ` Ed Tanous
2020-09-17 22:21   ` Khetan, Sharad
2020-09-21 15:05     ` Ed Tanous
2020-09-21 15:05       ` Ed Tanous
2020-09-22  2:03       ` Khetan, Sharad
2020-09-22  2:03         ` Khetan, Sharad
2020-09-22 16:54         ` Nancy Yuen
2020-09-21 12:55   ` Brad Bishop
2020-09-21 15:53     ` Ed Tanous
2020-09-21 17:52       ` Brad Bishop
2020-09-21 18:25         ` Ed Tanous
2020-09-21 19:08           ` Brad Bishop
2020-09-22 20:40         ` Vijay Khemka
2020-09-23 19:46           ` Ed Tanous [this message]
2020-09-23 19:49             ` Vijay Khemka
2020-09-21 18:20       ` Brad Bishop
2020-09-21 18:49         ` Ed Tanous
2020-09-21 19:01           ` Brad Bishop
2020-09-22 19:52       ` Vijay Khemka
2020-09-23 17:50 ` Brad Bishop

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='CACWQX82ARgwPo1LCWF3fYZtzXtj4p=ty43xN21qX9GOZdzLKhQ@mail.gmail.com' \
    --to=ed@tanous.net \
    --cc=bradleyb@fuzziesquirrel.com \
    --cc=openbmc@lists.ozlabs.org \
    --cc=vijaykhemka@fb.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.