On 12/20/2013 09:41 AM, Michal Privoznik wrote:
Ooh, just noticed that the timestamp is not part of the event data; probably worth adding another parameter to the callback function to list the event timestamp (as knowing when qemu fired an event may indeed be important to a developer using this interface for debugging). What type would be best? Is it okay to tie our public interface to struct timespec (which in turn risks problems if a compile-time switch can move between 32- and 64-bit seconds since Epoch), or should I just open-code it to two parameters: 'long long seconds, int microseconds'?
Well, in qemu code base it seems like they're using struct timeval; but typecasting into int64_t both seconds and microseconds. So I'd say it's fine for us to go with ULL seconds, uint microseconds. Although I'm not that convinced that we should stick with unsigned, signed type will work too. At least for another ~25 years on my RPi :)
I'm going signed LL for seconds (-1 if timestamp is not available), and uint for micros. Even if the host uses 32-bit time_t for seconds, it doesn't hurt us to pass the time as 64-bit; and by specifying it as explicit LL rather than time_t our header remains independent of host sizing changes. -- Eric Blake eblake redhat com +1-919-301-3266 Libvirt virtualization library http://libvirt.org