IPMI Sensor Name limitation of 16 bytes

Johnathan Mantey johnathanx.mantey at intel.com
Tue Jul 4 05:22:32 AEST 2023


On 6/30/23 02:04, Rohit Pai wrote:
>
> Hello Johnathan,
>
> Thanks for your reply.
>
> >> We're proposing adding a "ShortName" entry to the JSON 
> configuration file read by Entity Manager.
>
> Could you please add some more detail here, how this would be consumed 
> by ipmid ?
>
> The sensors can be created by an application, and we were looking to 
> do modification in one place where this conversion can happen.
>
> Also, as per your proposal we need to know all possible names of the 
> sensor per platform and configure it right ? We wanted to propose some 
> auto generation algorithms where it can take up any new sensors which 
> can get added or discovered. I agree with you on the point that auto 
> generation algorithms can produce mangled/duplicate names.
>
The current plan:

Modify phosphor-dbus-interfaces Sensor/Value.interface.yaml to include a 
"ShortName" string entry.

Modify EntityManager JSON input files to include a "ShortName" field. 
The "ShortName", in my current thought process, is optional. The intent 
is to use "Name" directly if it is already short enough to meet IPMI 
requirements.

Modify dbus-sensor daemons to properly generate short names based upon 
the "ShortName" string provided via D-Bus. The ShortName may need 
adjustment if the incoming string has fields that require regex 
modification. Once the final ShortName is computed it is stored as part 
of the 'struct Sensor' upon which most of the dbus-sensors are derived.

Modify phosphor-host-ipmid D-Bus SDR generation to use either "Name" or 
"ShortName". This will replace the code that generates the name from the 
D-Bus path string currently in use. The dbus-sensors code returns 
Value.interface entries with the "Name" or the "ShortName" fully formed. 
If the D-Bus record has a "ShortName" entry, use it directly. Otherwise 
use the "Name" entry directly.

The goal of following this model is to provide each OpenBMC vendor to 
control how sensor names are emitted. Another goal is to avoid receiving 
a series of defect reports issued by QA stating the name of IPMI sensors 
are suddenly significantly different that they were in prior releases of 
OpenBMC. The proposal here mitigates this second issue.

I am currently working on a project to do away with some portions of 
intel-ipmi-oem and migrating to phosphor-host-ipmid. I'm not certain I 
can continue the project if a significant change in how sensors are 
named is implemented.

<snip>

-- 
Johnathan Mantey
Senior Software Engineer
*azad te**chnology partners*
Contributing to Technology Innovation since 1992
Phone: (503) 712-6764
Email: johnathanx.mantey at intel.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ozlabs.org/pipermail/openbmc/attachments/20230703/cc5d7ee2/attachment.htm>


More information about the openbmc mailing list