Design proposal on removing /org/openbmc/settings/boot_policy"

[Patrick Williams]

On Thu, Aug 03, 2017 at 04:55:21PM +0530, vishwa wrote:
> Now, the proposal is to remove 
> '"/org/openbmc/settings/host0:boot_policy"' and then put this as a 
> boolean into 'persist' property into:
> 
> /xyz/openbmc_project/Control/Boot/Mode and 
> /xyz/openbmc_project/Control/Boot/Source.

I understand we have two different interfaces for these two different
properties but do we want them on a single object path?  It seems like
having multiple properties on /xyz/.../control/hostN/boot would be
better, but this will preclude using the same property name in both
interfaces.

> 
> IPMID would then look at this new boolean to see if its ONETIME ( 
> boolean : 0 ) or PERMANENT ( boolean : 1 ) and respond to Get-Boot-Options.

Why are we not instead creating two objects?  This proposal creates a
bit of undefined behavior in my mind:

1. Since only one dbus property ca be updated at a time, which order is
the user suppose to update?

2. What happens when the property is ONETIME (false), the value of Mode
itself is changed, and then the property is changed to PERMANENT (true)?
Does this restore the old value persisted or does it now persist the
previous ONETIME value?

3. As a user, how can I identify what the PERMANENT value is if someone
has temporarily done a ONETIME?  I have to wait until the ONETIME is
consumed?

It seems like having an optional, perhaps dynamically create, second
object to separate PERMANENT and ONETIME would take care of this,
wouldn't it?  Is there a reason you did not want to have two settings
objects to represent this?

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