qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [PATCH 2/3] qga: add guest-get-time command


From: mdroth
Subject: Re: [Qemu-devel] [PATCH 2/3] qga: add guest-get-time command
Date: Fri, 11 Jan 2013 11:28:11 -0600
User-agent: Mutt/1.5.21 (2010-09-15)

On Fri, Jan 11, 2013 at 03:37:26PM +0800, Lei Li wrote:
> On 01/08/2013 06:04 AM, Eric Blake wrote:
> >On 01/06/2013 03:06 AM, Lei Li wrote:
> >>Signed-off-by: Lei Li <address@hidden>
> >>---
> >>  qga/commands-posix.c |   12 ++++++++++++
> >>  qga/qapi-schema.json |   17 +++++++++++++++++
> >>  2 files changed, 29 insertions(+), 0 deletions(-)
> >>
> >>+++ b/qga/qapi-schema.json
> >>@@ -100,6 +100,23 @@
> >>               'utc-offset': 'int' } }
> >>  ##
> >>+# @guest-get-time:
> >>+#
> >>+# Get the information about host time in UTC and the
> >>+# UTC offset.
> >About the host time, or about the guest time?  In other words, doesn't
> >this command exist for the host to ask the guest what time the _guest_
> >thinks it is, so that the host can then decide whether to issue a
> >followup command to tell the guest to adjust its time?
> 
> No, this command is for getting host time. You might want to take a look at
> the RFC and the reply from Mike I sent few days ago for suggestions and
> discussions.
> 
> http://article.gmane.org/gmane.comp.emulators.qemu/186126

As mentioned elsewhere, what your guest-get-time implementation is actually
returning is the guest time. But that's exactly what we want, since it
provides all the information the host needs to calculate what value it
should pass to guest-set-time (really we just need the utc-offset for this,
but the other values are useful for other use cases. In fact, if you
document guest-*-time to always return values relative to UTC 1970 epoch, we
don't even actually need *that* unless we need to change the guest utc-offset
for some reason, but again, nice to handle other use cases) 

> 
> >>+#
> >>+# This command tries to get the host time which is
> >>+# presumably correct, since need to be able to resynchronize
> >>+# clock to host in guest.
> >>+#
> >>+# Returns: @HostTimeInfo on success.
> >For that matter, should we name the type in patch 1/3 'TimeInfo',
> >instead of 'HostTimeInfo', as it is not intrinsically tied to host or
> >guest, but more a function of who is being queried?
> 
> Yes, it make sense. Luiz feel confused about this 'HostTimeInfo' too,
> I think 'TimeInfo' might be a good idea. :)

Fourth'd :)

> 
> 
> 
> -- 
> Lei
> 



reply via email to

[Prev in Thread] Current Thread [Next in Thread]