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(a)veillard.com | Rpmfind RPM search engine
http://rpmfind.net/
http://veillard.com/ | virtualization library
http://libvirt.org/