| Message ID | 8c78bfbfd63d505ce4f5e8949fb118c02febac0f.1421742507.git.mprivozn@redhat.com |
|---|---|
| State | New |
| Headers | show |
On 01/20/2015 01:30 AM, Michal Privoznik wrote: > The command implementation for Windows guest has this limitation. If > no time to set has been provided the documentation for the command > states that time should be read from RTC. However, on Windows bare > GetSystemTime() is used, which does not read anything from RTC rather > than return system time. Yeah, that system time which is wrong (after > stop & cont) and which we want to set. > > However, there's no simple way to read RTC on windows yet [1], so > until the time somebody comes with bright implementation, we should at > least document the command implementation limitation. I think it would be wiser to update the Windows guest-agent code to explicitly fail instead of calling a useless GetSystemTime(), if we can't meet the documented semantics of calling the function without a timestamp. > > 1: http://msdn.microsoft.com/en-us/library/aa908981.aspx > > Signed-off-by: Michal Privoznik <mprivozn@redhat.com> > --- > qga/qapi-schema.json | 5 ++++- > 1 file changed, 4 insertions(+), 1 deletion(-) > > diff --git a/qga/qapi-schema.json b/qga/qapi-schema.json > index 376e79f..91821ef 100644 > --- a/qga/qapi-schema.json > +++ b/qga/qapi-schema.json > @@ -121,7 +121,10 @@ > # given value, then sets the Hardware Clock (RTC) to the > # current System Time. This will make it easier for a guest > # to resynchronize without waiting for NTP. If no @time is > -# specified, then the time to set is read from RTC. > +# specified, then the time to set is read from RTC. On Windows > +# guests there's implementation limitation that does not read the > +# time from RTC if no time has been provided. Users are advised > +# to allways pass a value for Windows guests. Grammar is awkward, and there's a typo in 'allways'. If we are okay with just a doc change (although I argued above that we really should have a code change), then I'd go with something more like: In the current implementation, Windows guests are unable to read time from the RTC, so users are advised to always pass a value.
diff --git a/qga/qapi-schema.json b/qga/qapi-schema.json index 376e79f..91821ef 100644 --- a/qga/qapi-schema.json +++ b/qga/qapi-schema.json @@ -121,7 +121,10 @@ # given value, then sets the Hardware Clock (RTC) to the # current System Time. This will make it easier for a guest # to resynchronize without waiting for NTP. If no @time is -# specified, then the time to set is read from RTC. +# specified, then the time to set is read from RTC. On Windows +# guests there's implementation limitation that does not read the +# time from RTC if no time has been provided. Users are advised +# to allways pass a value for Windows guests. # # @time: #optional time of nanoseconds, relative to the Epoch # of 1970-01-01 in UTC.
The command implementation for Windows guest has this limitation. If no time to set has been provided the documentation for the command states that time should be read from RTC. However, on Windows bare GetSystemTime() is used, which does not read anything from RTC rather than return system time. Yeah, that system time which is wrong (after stop & cont) and which we want to set. However, there's no simple way to read RTC on windows yet [1], so until the time somebody comes with bright implementation, we should at least document the command implementation limitation. 1: http://msdn.microsoft.com/en-us/library/aa908981.aspx Signed-off-by: Michal Privoznik <mprivozn@redhat.com> --- qga/qapi-schema.json | 5 ++++- 1 file changed, 4 insertions(+), 1 deletion(-)