Storing host data on the BMC

[Patrick Williams]

On Thu, May 14, 2020 at 09:13:47AM +0530, Deepak Kodihalli wrote:
> On 14/05/20 2:48 am, Patrick Williams wrote:
> > On Wed, May 13, 2020 at 08:37:32PM +0530, Sunitha Harish wrote:
 
> I think the current proposal from Surya enables this already. Do you 
> just mean the design doc should explicitly state this isn't restricted 
> to the "BIOS" firmware.

Yep.

> As far as Sunitha's question goes, my point is that not all host 
> firmware generated data is a BIOS attribute. For eg if the host tells me 
> about the presence of certain FRUs, or their functional states, I 
> wouldn't want to store those in the BIOS attributes backend, I'd rather 
> associates those with the existing D-Bus interfaces for the FRU 
> inventory. I think the same applies to the Origin property that has been 
> described - associate with the networking D-Bus backend.

I think we're in agreement here.  Data which is interesting to represent
on the BMC, for which we already have a defined-interface, use it.  For
data which isn't interesting the to BMC, use the generic BIOS attribute
table.

> > If you are wanting the data to be managed, utilizing existing DBus
> > interfaces we have around networking, doesn't phosphor-settingsd cover
> > that from an implementation perspective?
> 
> I don't think the 'Origin' property is a setting.

Well the name "settingsd" is somewhat arbitrary based on its original
definition.  I believe the current implementation can make a placeholder
instance of any dbus interface.

Having said that, one weakness with settingsd is that you can't easily
restrict property changes to data coming from the host.  Once you make a
settingsd object, anyone can make dbus calls to change properties on it.
If we want to be able to restrict that to specific interfaces, we might
want to look at a phosphor-inventory-manager like implementation which
has a special "backdoor" method to create / update the instances but
prevents modification through the normal property change interfaces.

-- 
Patrick Williams
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://lists.ozlabs.org/pipermail/openbmc/attachments/20200514/f3ca5618/attachment.sig>