Refactor phosphor-settingsd

[Deepak Kodihalli]

Hello All,

I'm working this sprint on refactoring the existing phosphor-settingsd 
application (https://github.com/openbmc/phosphor-settingsd). This 
application provides and implements interfaces to let the user configure 
system settings. One of the first goals is to write d-bus interfaces, in 
YAML, around various settings, and place them in the 
phosphor-dbus-interfaces repository.

With the existing settings application, there isn't a clear schema 
around each setting, they are all described by a single 
org.openbmc.settings.Host interface. We'd ideally want an interface 
clearly describing each setting. That also makes it possible to 
implement settings d-bus objects as needed by a system.

Looking for feedback on these points :

1) Where to place settings d-bus interfaces? For example let's say 
there's a "boot_media" setting which indicates the source of the host 
image (disk/network/etc). The interface could be either 
xyz/openbmc_project/Settings/Host/BootMedia.interface.yaml or 
xyz/openbmc_project/Control/Host/BootMedia.interface.yaml. Apart from 
organizational clarity, any other advantages of placing all Settings 
interfaces under a common 'Settings' namespace? Any disadvantages? Is it 
more intuitive to place the interfaces in an already existing namespace 
describing the object on which this setting applies? For instance, what 
would be the best place to house an interface describing a CPU setting? 
We already have an 'Inventory' namespace for items such as the CPU.

2) While 1) above is more of an organizational statement, the same 
problem applies to object paths of the d-bus objects implementing 
settings. An obvious advantage of having all settings d-bus objects 
under xyz/openbmc_project/settings/ would be that they are easy to find 
and enumerate. The disadvantage would be extra work to identify unique 
path names. The alternative would be to have the settings objects under 
the existing namespace of the object they are applied to, for example 
xyz/openbmc_project/inventory/system/motherboard/cpu0/some_cpu_setting. 
Any preferences here?

3) Creating system specific settings d-bus objects - this for example 
means certain settings d-bus objects nay not even be created for certain 
systems. I'm thinking this can be achieved via a policy file (in YAML), 
which states what settings interfaces to implement. If there's a 
possibility of different kind of objects implementing the same 
interface, or the same kind of objects implementing different 
interfaces, then the policy file will have to talk about objects as 
well. I guess point 2) has a bearing here.

Thanks,
Deepak