RFC: new design of phosphor-time-manager on sdbusplus

[Mine]

Hi Deepak

On Fri, Jan 13, 2017 at 5:11 PM, Deepak Kodihalli
<dkodihal at linux.vnet.ibm.com> wrote:
> Hello Lei,
>
>
> On 13/01/17 1:12 pm, Mine wrote:
>>
>> I’d like to discuss the design of |phosphor-time-manager| with the new
>> sdbusplus interfaces.
>>
>> Please see below background and new design, let me know if you have any
>> comments.
>> Thanks!
>>
>>
>>       Background
>>
>> Legacy time-manager expose below interfaces and methods:
>>
>>   * curr_time_mode
>>   * curr_time_owner
>>   * requested_time_mode
>>   * requested_time_owner
>>   * GetTime(target)
>>   * SetTime(target, time)
>>
>> The implementation of |Get/SetTime()| will check the current time mode
>> and owner, and do below:
>>
>>   * For |GetTime(<target>)|:
>>       o If target is “bmc”, return BMC time;
>>       o If target is “host”, return Host time;
>>       o Else, return error
>>   * For |SetTime(target, time)|:
>>       o If target is “bmc”:
>>           + If mode is NTP, return error
>>           + If owner is “HOST”, return error
>>           + Set BMC time
>>       o If target is “host”:
>>           + If owner is “BMC”, return error
>>           + Set Host time
>>           + If owner is “SPLIT”, save the diff between BMC time and Host
>>             time;
>>
>>
>>       New Design
>>
>> Now with sdbusplus, we have EpochTime interface, with |elapsed| property.
>>
>> After discussion with Li Yi and Vishwa, we decided to implement as below:
>>
>> Create two objects:
>>
>>   * |BmcEpoch|
>>   * |HostEpoch|
>
>
>
> Could these be just associations (via the association interface) to a single
> object? I'm not sure if the user the Epoch interface knows Host vs BMC?
> Shouldn't that be picked from the settings, or do we really have explicit
> calls to fetch/set bmc and host time?
>
According to Vishwa, it is a requirement for time manager to keep both
BMC and HOST time.

And from previous design, whether the settings' time_owner is BMC or
HOST or else,
the user of time-manager will get/set the BMC or HOST time.
E.g.
1. Host's IPMI SEL_SET_TIME will set HOST time.
    In this case, with Epoch interface, hostipmid will set HostEpoch
service's "elasped" property.
2. User is able to see both BmcEpoch and HostEpoch service on DBus,
and he is free to
get/set the "elasped" property on each service.
    The implementation will handle if the set should succeed or not.

>> They both implements EpochTime interface.
>>
>> For |BmcEpoch|:
>>
>>   * When |elapsed()| is called, return BMC time;
>>   * When |elapsed(us)| is called, use above SetTime(“bmc”) logic
>>
>> For |HostEpoch|:
>>
>>   * When |elapsed()| is called, return HOST time;
>>   * When |elapsed(us)| is called, use above SetTime(“host”) logic.
>>
>> And there will be no “curr_time_mode/owner” or
>> “requested_time_mode/owner” properties on DBUS.
>>
>> --
>> BRs,
>> Lei YU
>
>
> Regards,
> Deepak
>
>>
>>
>>
>> _______________________________________________
>> openbmc mailing list
>> openbmc at lists.ozlabs.org
>> https://lists.ozlabs.org/listinfo/openbmc
>>
>
> _______________________________________________
> openbmc mailing list
> openbmc at lists.ozlabs.org
> https://lists.ozlabs.org/listinfo/openbmc