Re: [libvirt] [RFC PATCH] qemu: new API for tracking arbitrary monitor events

> 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 :)