On Wed, Apr 02, 2014 at 05:44:16AM -0600, Eric Blake wrote:
On 04/02/2014 03:34 AM, Michal Privoznik wrote:
> If we'd come up with a struct to interpret the time, it's written
> in stone and there's nothing we can do about it. Even if we break
> up the struct into function arguments. However, we can use typed
> parameters and have the API extensible. For example, I'm
> implementing seconds granularity only for now. If later somebody
> feels like he/she wants to use even finer granularity, we can do
> that by inventing a new typed param. Same goes for timezone, etc.
But what more is there to add besides seconds and nanoseconds (struct
timespec)? We don't have to support full resolution of nanoseconds, and
could either document that we round (possibly to as course as seconds)
or reject input with non-zero nanoseconds if we don't want to support
sub-seconds right away. It just feels awkward to me to have to bundle
something into a virTypedParam when the most we could ever extend this
to is struct timespec, so representing struct timespec via split
parameters from the get-go requires less thought when using the interface.
I think I'm inclined to agree that we shouuld just use an long long timesecs
and possibly a second long long timenanosecs.
People won't normally update the timezone at the same time as updating the
BIOS time and vica verca. So in the event we ever wanted to update the
timezone I could see that being a separate virDomainSetGuestTimezone API.
Regards,
Daniel
--
|:
http://berrange.com -o-
http://www.flickr.com/photos/dberrange/ :|
|:
http://libvirt.org -o-
http://virt-manager.org :|
|:
http://autobuild.org -o-
http://search.cpan.org/~danberr/ :|
|:
http://entangle-photo.org -o-
http://live.gnome.org/gtk-vnc :|