Refactor phosphor-settingsd

[Deepak Kodihalli]

On 10/05/17 11:13 pm, Deepak Kodihalli wrote:
> 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


Based on the above I went ahead and put code for review. The d-bus 
interfaces are at https://gerrit.openbmc-project.xyz/#/c/4205/ and the 
settings manager application is at 
https://gerrit.openbmc-project.xyz/#/c/4244/. There's a README in this 
commit chain explaining some of the design.

I went the route of having a separate interface per setting, instead of 
a generic setting interface (having for example a single d-bus variant 
property) because with the latter there's no schema to define a setting. 
For instance, a setting could actually be more than one property, or be 
an enumeration.

Thanks,
Deepak