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
Attachment:
signature.asc
Description: OpenPGP digital signature
-- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list