Mapping standard D-Bus sensors to ProcessorMetrics (and other specific schemas)

[Ambrozewicz, Adrian]

W dniu 4/9/2021 o 14:05, Patrick Williams pisze:
> 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.
> 

Please see message from Ed, as he's supposedly proposing to follow that 
path. I don't have strong opinions on one or the other approach.

>> 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
> 
Thanks for the link. I linked my sensor to concrete CPU with 
Association, similarly to already existing bmcweb Processors node 
implementation. Will your extension be able to provide even 'deeper' 
associations? For ProcessorMetrics we would need to map for CPU_X\Core_Y.

I've read the design, however one thing is not clear for me. My current 
understanding was that for each association there would need to exist 
some D-bus object at given path somewhere. Would i need my CPU inventory 
service to also expose separate objects for each core for my association 
to be 'legal', or could we represent some virtual hierarchy with no 
actual D-Bus object in the system?

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

In given example I would like my sensor to be source of information for 
property defined by ProcessorMetrics schema. In the example I've used 
property associated with given Core, thus CoreMetrics/12/UnhaltedCycles 
maps directly to ProcessorMetrics sub-property. Enumerations could be 
not enough as we have multiple informations to represent:
- association with given processor (done by ProcessorMetrics)
- association with given core (could that be handled by your proposed 
design?)
- linking to given property

Would the enumeration be used for the last element, while leaving 
hierarchy problem to Associations?