All of lore.kernel.org
 help / color / mirror / Atom feed
From: Patrick Williams <patrick@stwcx.xyz>
To: "Ambrozewicz, Adrian" <adrian.ambrozewicz@linux.intel.com>
Cc: "openbmc@lists.ozlabs.org" <openbmc@lists.ozlabs.org>
Subject: Re: Mapping standard D-Bus sensors to ProcessorMetrics (and other specific schemas)
Date: Fri, 9 Apr 2021 07:05:53 -0500	[thread overview]
Message-ID: <YHBDIZqvHI0THFh3@heinlein> (raw)
In-Reply-To: <f9127788-7f8a-59ed-e434-0f510773d2aa@linux.intel.com>

[-- Attachment #1: Type: text/plain, Size: 2033 bytes --]

On Wed, Apr 07, 2021 at 02:24:55PM +0200, Ambrozewicz, Adrian wrote:
> Question of extending xyz.openbmc_project.Sensor.Value interface (so it 
> allows for more types or nested paths, if necessary) is something  I 
> know should be considered, but seems like more or less straightforward 
> to address.

I suspect this would be the more difficult direction to go down.  There
is already enough code that looks for sensors at specific paths that
you'd have to track down and fix up.  Also, there has been some concern
by some maintainers in other cases about having information in the paths
have meaning and prefering to reduce the reliance on that.

> There is bigger issue I see now - mapping D-Bus sensors to concrete 
> Redfish properties. Mapping sensors at inventory level is sorted out 
> with use of xyz.openbmc_project.Association.Definitions interface. 
> However - I don't see (or know of) any method to link given D-Bus sensor 
> with it's designated place in Redfish schema.

I think associations are the right approach to link sensors with
inventory items.  There is a design document underway to define some of
those assocations for inventory items and it seems like your needs
should be an extension to that.

https://gerrit.openbmc-project.xyz/c/openbmc/docs/+/41468/4/architecture/dbus-inventory.md

> I've done some PoC implementation of ProcessorMetrics, which relies on 
> new D-Bus interface with 'Mapping' property (eg. 'TemperatureCelsius' or 
> 'CoreMetrics/12/UnhaltedCycles'). ProcessorMetrics node implementation 
> queries D-Bus for all sensors associated with given CPU and populates 
> properties if proper mapping was found.

I'm not really grasping what the contents of this mapping property are.
Generally we want to stay away from free-form strings having programatic
uses.  Maybe if you can define these mappings as enumerations?

What is the additional information you need besides the assocation from
a sensor to its inventory item?

-- 
Patrick Williams

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

  reply	other threads:[~2021-04-09 12:06 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-04-07 12:24 Mapping standard D-Bus sensors to ProcessorMetrics (and other specific schemas) Ambrozewicz, Adrian
2021-04-09 12:05 ` Patrick Williams [this message]
2021-04-27 11:52   ` Ambrozewicz, Adrian
2021-05-11 14:52     ` Patrick Williams
2021-05-11 16:26       ` Ed Tanous
2021-05-12 11:17         ` Ambrozewicz, Adrian
2021-05-17  7:38           ` Ambrozewicz, Adrian
2021-04-09 15:27 ` Ed Tanous
2021-04-27 11:38   ` Ambrozewicz, Adrian
2021-05-11 16:16     ` Ed Tanous

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=YHBDIZqvHI0THFh3@heinlein \
    --to=patrick@stwcx.xyz \
    --cc=adrian.ambrozewicz@linux.intel.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.