[libvirt] [PATCH 2.5/7] maint: prefer newer API names internally

Eric Blake eblake at redhat.com
Wed May 18 16:32:29 UTC 2011


On 05/18/2011 10:14 AM, Daniel P. Berrange wrote:
> 
> While the structs are ABI compatible, this still constitutes a change
> in API. ie apps doing this
> 
>   int np = 5;
>   struct _virMemoryParameter p[np];

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.

You should instead be using the public typedef:

int np = 5;
virMemoryParameter p[np];

> 
>   virDomainGetSchedulerParameters(dom, p, &np);

And since virMemoryParameter and virTypedParameter are two typedefs for
the same type, they shouldn't get a compiler warning.

> 
> 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.

Does your NACK still hold with my explanation?  Do I need to prepare a
v2 that just changes internal names but not the public API use of the
old names?

-- 
Eric Blake   eblake at redhat.com    +1-801-349-2682
Libvirt virtualization library http://libvirt.org

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 619 bytes
Desc: OpenPGP digital signature
URL: <http://listman.redhat.com/archives/libvir-list/attachments/20110518/baefcca8/attachment-0001.sig>


More information about the libvir-list mailing list