All of lore.kernel.org
 help / color / mirror / Atom feed
From: Ed Tanous <ed@tanous.net>
To: Brad Bishop <bradleyb@fuzziesquirrel.com>
Cc: OpenBMC Maillist <openbmc@lists.ozlabs.org>
Subject: Re: interest in a minimal image recipe
Date: Mon, 21 Sep 2020 11:25:34 -0700	[thread overview]
Message-ID: <CACWQX82EdUFtBDK6Vt=-CKyKxN9WFdFGX_j8mhBbNDScxf7OaA@mail.gmail.com> (raw)
In-Reply-To: <20200921175227.zmdjbmixbwvstd4m@thinkpad.fuzziesquirrel.com>

On Mon, Sep 21, 2020 at 10:52 AM Brad Bishop
<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.

That makes a lot more sense now.

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

Yep, although I think it's a solvable problem to make it an
image/distro feature.

>
> But in any case, intel-ipmi-oem requires entity-manager, not the other
> way around right?

Good point.  I never thought of it that way, but you're 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.

Yep. That looks like what I would expect.

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

That's a really good point.  We really ought to model features as
outbound interfaces that drive internal RDEPENDS.  Ideally nobody
would be appending entity-manager, they would be appending
intel-ipmi-oem (or whatever name we pick for it in the future), which
would have the correct dependencies on entity-manager.   I like it.

  reply	other threads:[~2020-09-21 18:27 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 [this message]
2020-09-21 19:08           ` Brad Bishop
2020-09-22 20:40         ` Vijay Khemka
2020-09-23 19:46           ` Ed Tanous
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='CACWQX82EdUFtBDK6Vt=-CKyKxN9WFdFGX_j8mhBbNDScxf7OaA@mail.gmail.com' \
    --to=ed@tanous.net \
    --cc=bradleyb@fuzziesquirrel.com \
    --cc=openbmc@lists.ozlabs.org \
    /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.