On Mon, Aug 13, 2007 at 12:45:39PM +0100, Daniel P. Berrange wrote:
On Mon, Aug 13, 2007 at 05:45:27AM -0400, Daniel Veillard wrote:
On Fri, Aug 10, 2007 at 03:35:08PM +0100, Richard W.M. Jones wrote:
This is the implementation (currently Xen, local only).
Thanks !
+++ include/libvirt/libvirt.h.in 10 Aug 2007 14:30:21 -0000 @@ -14,6 +14,9 @@ #ifndef __VIR_VIRLIB_H__ #define __VIR_VIRLIB_H__
+#include <sys/types.h> +#include <stdint.h> + [...] +struct _virDomainBlockStats { + int64_t rd_req;
That's my only worry at the moment. stdint.h isn't really that portable, we want to define an 64bits unsigned field, but we already use unsigned long long in libvirt.h . I would be tempted to rationalize this, either we think (stdint.h/int64_t) is more portable or long long is the one, but I would prefer if we picked one and stick with it at the API level.
I don't mind one way or the other - there's not really much to choose between them - int64_t is POSIX, while long long is C99. So both are 'standards'. They've both been available on Linux & Solaris for as long as I can remember.
# info gcc "5.8 Double-Word Integers ========================
ISO C99 supports data types for integers that are at least 64 bits wide, and as an extension GCC supports them in C89 mode and in C++. Simply write `long long int' for a signed integer, or `unsigned long long int' for an unsigned integer. "
# info inttypes.h "If an implementation provides integer types with width 64 that meet these requirements, then the following types are required: int64_t uint64_t"
Rock, paper, scissors. C99 wins!
The only difference is that in some future (hopefully we will be retired by then ;-) long long may actually end up being say 128bits on some hardware. Honnestly I don't care, since we are already using unsigned long long in the header then let's stick to it and use it for the statistics too. Daniel -- Red Hat Virtualization group http://redhat.com/virtualization/ Daniel Veillard | virtualization library http://libvirt.org/ veillard@redhat.com | libxml GNOME XML XSLT toolkit http://xmlsoft.org/ http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/