On Thu, Sep 17, 2020 at 01:10:06PM +0530, Ratan Gupta wrote:
> We need to address the below two concerns with the existing settings infra.

Both of these seem like missing features based on our now greater
understanding of the problem domain from where we were 3-4 years ago
when phosphor-settings-manager was originally written, right?  That
doesn't seem like a good reason to entirely throw out the approach.

>   * Pending v/s configured value: Currently settings have single Dbus
>     Object, Some properties which is for host firmware we need to have
>     two placeholders one for Pending values and one for Configured
>     values. Bios settings have this concept.
>       o Should we add two Dbus objects in settings infra?

This was going to be my suggestion, yes.  You could have two sets of the
objects: current and pending.  'current' objects may not be written by
dbus-clients.  These are the same terms used by the BIOSConfig proposal.

What I am not seeing in BIOSConfig and is equally applicable here is
_when_ pending is applied to current.  You will need some interface that
IPMI / PLDM can call to apply those settings?  Or, do you monitor host
state signals automatically?

>   * Dynamic Dbus objects: Currently settings infrastructure is only for
>     static objects, Objects which gets added on runtime, settings infra
>     doesn't support that.
>       o Eg: IP address on ethernet interface is dynamic in nature, An
>         ethernet interface can have multiple IP address on it.
>         considering if SLAAC is enabled(ipV6).
>       o Seems this problem is common for both(settings v/s bios-settings)

I assume these would be requested for creation by IPMI / PLDM?  We could
use a similar model to xyz.openbmc_project.Inventory.Manager where
objects are requested for creation dynamically through a method.

-- 
Patrick Williams