On Fri, Sep 02, 2011 at 08:05:14AM -0600, Eric Blake wrote: > On 09/02/2011 04:06 AM, Daniel Veillard wrote: > >On Wed, Aug 31, 2011 at 04:26:06PM +0800, Osier Yang wrote: > >>--- > >> include/libvirt/libvirt.h.in | 111 ++++++++++++++++++++++++++++++++++++++++++ > >> src/libvirt_public.syms | 5 ++ > >> 2 files changed, 116 insertions(+), 0 deletions(-) > >> > >>+/** > >>+ * virDomainBlockStatsFlagsStruct: > >>+ * > >>+ * Struct filled by virDomainBlockStatsFlags() providing information > >>+ * about the block device. > >>+ * > >>+ * Hypervisors may return a field set to ((long long)-1) which indicates > >>+ * that the hypervisor does not support that statistic. > >>+ * > >>+ * NB. Here 'long long' means 64 bit integer. > >>+ */ > >>+typedef struct _virDomainBlockStatsFlags virDomainBlockStatsFlagsStruct; > >>+ > >>+struct _virDomainBlockStatsFlags { > >>+ char field[VIR_DOMAIN_BLOCK_STATS_FIELD_LENGTH]; > >>+ long long value; > >>+}; > > Are we positive that all useful block stats will always be in long > long format, or should we reuse virTypedParameter here to also allow > other typed objects in the future? Ouch, very good point ! We can't guess so we should not take the risk ! we really ought to align to the other APIs and use virTypedParameter Daniel -- Daniel Veillard | libxml Gnome XML XSLT toolkit http://xmlsoft.org/ daniel@xxxxxxxxxxxx | Rpmfind RPM search engine http://rpmfind.net/ http://veillard.com/ | virtualization library http://libvirt.org/ -- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list