dkodihal at linux.vnet.ibm.com
Thu May 11 03:43:59 AEST 2017
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
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/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
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.
More information about the openbmc