<div dir="ltr"><div dir="ltr">Hi,<br><br>We have some user defined host settings which we are presently keeping it in phosphor-settings-manager and the associated pldm bios attributes are there in the pldm BIOS table. Few properties in the object hosted by the phosphor-settings-manager are read-only for out of band but through in-band it can be changed.<br><br>For example; the IP origin (static/dhcp) in the below commit.<br>      <a href="https://gerrit.openbmc-project.xyz/#/c/openbmc/meta-ibm/+/30205/">https://gerrit.openbmc-project.xyz/#/c/openbmc/meta-ibm/+/30205/</a><br><br>UseCase: The redfish client will set the hypervisor IP address via bmcweb. This will be taken to the hypervisor via pldm. Once the system is powered on, the hypervisor will apply the IP address to its Ethernet Interface. Properties like IPAddress, SubnetMask, Gateway are having one to one mapping in the PLDM BIOS attr table and Dbus object properties, Now concern here is on the Origin property which PLDM reads as sensor from Hypervisor.<br><br>We have two views on this scenario.<br>View 1: These are not suitable to be stored in the existing phopsphor-settings-manager since these are not the writable out-of-band user settings. <br>View 2: These sensors can be part of this settings table, can be considered as a read-only attribute for the out-of-band access. These can be writable to the host. <br><br>I understand that there are some efforts going on by Intel to come up with internal Bios settings table but this problem is agnostic to whether we keep the data in settings Dbus object or in the new app which is array of key-value pairs.<br><br>Below are the two solutions which i can think of:<br>-------------------------------------------------------------<br>1. Let there be an attribute in the existing BIOS attribute table (Settings Storage), which will be settable from the hypervisor through PLDM, however pldm reads it as a sensor.This setting will be read-only for the out-of-band clients(redfish). This approach is something similar to the redfish schema, where we implement the writable & read-only attributes in the same schema/resource. Redfish also has the origin as a settings but they made it as a read-only attribute. This helps in bringing the related attributes together under same object.<br><br>2. Let create a new table/object for mapping of pldm sensors ; the Sensors Storage table which will contain only those attributes which are mapped to the pldm sensors. This sensor table can be set by the pldm, and other interested components can read this to get the required attribute values. If we do this, then openBMC would be having two tables 1) Settings Storage for Bios settings 2) Sensors Storage for pldm sensors. It is kind of bringing the pldm complexities to the external application. Also complexities involved in bringing the related attributes together from two different tables.<br><br>Please let me know your views on these.  What could be the better long term solution for this?  <br>It would be great if you can propose any other way of handling this.<br><br>Thanks & regards,<br>Sunitha</div><div dir="ltr"><br></div></div>