<div dir="ltr">Hi Vishwa,<br><br>On Wed, Jan 18, 2017 at 7:07 PM, vishwa <<a href="mailto:vishwa@linux.vnet.ibm.com">vishwa@linux.vnet.ibm.com</a>> wrote:<br>> On 01/17/2017 01:21 PM, Mine wrote:<br>>><br>>> Hi Patrick,<br>>><br>>> On Tue, Jan 17, 2017 at 3:44 AM, Patrick Williams <<a href="mailto:patrick@stwcx.xyz">patrick@stwcx.xyz</a>><br>>> wrote:<br>>>><br>>>> On Fri, Jan 13, 2017 at 03:42:50PM +0800, Mine wrote:<br>>>>><br>>>>> New Design<br>>>>><br>>>>> Create two objects:<br>>>><br>>>> You mean 'classes' or 'objects'?  I think you mean two classes, which<br>>>> initially we will only have 1 instance of each.  Please make sure the<br>>>> HostEpoch implementation can relatively-easily be enhanced to have<br>>>> multiple instances.<br>>><br>>> I should be meant to create two "instances" on the bus, eventually it<br>>> looks<br>>> something like:<br>>> ```<br>>> xyz.openbmc_project.Time.Manager<br>>>      /xyz/openbmc_project/time/host_epoch<br>>>          org.freedesktop.DBus.Peer<br>>>          org.freedesktop.DBus.Introspectable<br>>>          org.freedesktop.DBus.Properties<br>>>          xyz.openbmc_project.Time.EpochTime<br>>>      /xyz/openbmc_project/time/bmc_epoch<br>>>          org.freedesktop.DBus.Peer<br>>>          org.freedesktop.DBus.Introspectable<br>>>          org.freedesktop.DBus.Properties<br>>>          xyz.openbmc_project.Time.EpochTime<br>>><br>>> ```<br>>> The service's BUSNAME is still `xyz.openbmc_project.Time.Manager`, and<br>>> it creates two objects, one for BmcEpoch and the other for HostEpoch, who<br>>> both implement xyz.openbmc_project.Time.EpochTime interface.<br>><br>> So TimeManager still owns the responsibility of maintaining offsets etc<br>> right ?<div><br><div>Not exactly, HostEpoch will own the offset and maintain it.</div><div>But yes, overall HostEpoch is part of TimeManager, so you can say TimeManager owns the offset as well.</div><div><br></div><div>><br></div><div>>>>>     - BmcEpoch<br>>>>>     - HostEpoch<br>>>>><br>>>>> They both implements EpochTime interface.<br>>>>><br>>>>> For BmcEpoch:<br>>>>><br>>>>>     - When elapsed() is called, return BMC time;<br>>>>>     - When elapsed(us) is called, use above SetTime(“bmc”) logic<br>>>>><br>>>>> For HostEpoch:<br>>>>><br>>>>>     - When elapsed() is called, return HOST time;<br>>>>>     - When elapsed(us) is called, use above SetTime(“host”) logic.<br>>>><br>>>> Seems ok.<br>>>><br>>>> The errors also need to be converted to dbus-defined errors, right?<br>>>><br>>>>> And there will be no “curr_time_mode/owner” or<br>>>>> “requested_time_mode/owner”<br>>>>> properties on DBUS.<br>>>><br>>>> So these are only stored in phosphor-settingsd now or are they also used<br>>>> internally for decisions?  I believe the previous implementation had<br>>>> them exposed more for debug purposes.  Are you going to add them to the<br>>>> journal at least?<br>>><br>>> Yes, the time_mode and time_owner are still stored in<br>>> phosphor-settingsd, and they<br>>> are used internally by phosphor-time-manager, which will register<br>>> callback for the<br>>> settings' change and handled accordingly.<br>>> The difference from the previous implementation is that we do not expose<br>>> these<br>>> settings in time-manager's DBus now.<br>>><br>>> What do you mean by "add them to the journal"?<br>><br>> I believe he is asking you to put that information in the journal traces so<br>> that we can use them for debug. I think you don't need anything more to<br>> cater to that request as the original implementation already puts those as<br>> journal traces.</div><div><br></div><div>Sure.</div><div>The code will use sdbusplus's logging to send journal logs.<br><br></div><div>>><br>>><br>>>> --<br>>>> Patrick Williams<br>>><br>>> _______________________________________________<br>>> openbmc mailing list<br>>> <a href="mailto:openbmc@lists.ozlabs.org">openbmc@lists.ozlabs.org</a><br>>> <a href="https://lists.ozlabs.org/listinfo/openbmc">https://lists.ozlabs.org/listinfo/openbmc</a><br>><br>><br><br></div></div></div>