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@xxxxxxxxxx +1-801-349-2682 Libvirt virtualization library http://libvirt.org
Attachment:
signature.asc
Description: OpenPGP digital signature
-- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list