On 05/18/2011 10:55 AM, Daniel P. Berrange wrote:
Apps shouldn't be doing this (struct _virMemoryParameter is a private name). Furthermore, we already deleted that private name in patch 1/7; applications using the private name will now be declaring an incomplete type, which explains the warning you saw in your demo program.
IMHO 'struct _virMemoryParameter' is just as much a public name as anything else in the public header file. The typedef serves as convenient syntactic sugar, but using either is valid for app developers, so we should not be deleting it.
Then I'm working on a patch to restore the missing names (I deleted _virMemoryParameter, _virBlkioParameter, and _virSchedParameter).
will get a compile warning/error
demo.c: In function ‘main’: demo.c:35:3: warning: passing argument 2 of ‘virDomainGetSchedulerParameters’ from incompatible pointer type demo.c:25:12: note: expected ‘virTypedParameterPtr’ but argument is of type ‘struct _virMemoryParameter *’
so NACK to this change.
Even if you convince me to not change the public signatures of the functions that existed prior to 0.9.2, I still think that it is worth changing the signature of virDomainSetSchedulerFlags (since we haven't released it yet), as well as all internal signatures.
I think we could perhaps achieve the same cleanup using #defines instead of typedefs, which would avoid breaking app code.
Indeed, and I'll give that a shot for restoring the old names. The goal here is ABI stability (the bits are the same, regardless of when it was compiled - we have that) and API stability (recompiling works without introducing new warnings or errors while using the old names - patch 1/7 broke that for the leading _ names). -- Eric Blake eblake@redhat.com +1-801-349-2682 Libvirt virtualization library http://libvirt.org