On 05/11/2011 06:16 PM, Stefan Berger wrote:
> On 05/11/2011 06:32 PM, Eric Blake wrote:
>> The public API has no flags argument, so neither should the internal
>> callback API. This simplifies the RPC generator.
>>
>>
>> static virNWFilterPtr
>> nwfilterDefine(virConnectPtr conn,
>> - const char *xml,
>> - unsigned int flags ATTRIBUTE_UNUSED) {
>> + const char *xml)
>> +{
>> virNWFilterDriverStatePtr driver = conn->nwfilterPrivateData;
>> virNWFilterDefPtr def;
>> virNWFilterObjPtr nwfilter = NULL;
> I assume this causes not interoperability problems between libvirt
> versions. I initially introduced the flag because other define functions
> had it also and thought I'd leave the option of having flags open.
For a single libvirt binary, there are no issues (the driver code is
linked privately, and we are allowed to change the API of anything in
libvirt_private.syms without impact to public interfaces). And between
libvirt binaries, we have the fortunate situation that the over-the-wire
protocol didn't pass a flags argument. Thus, when calling the API, you
had this scenario:
virNWFilterDefineXML(no flags) -> remote callback(0 flag) -> RPC
over-wire format (no flags) -> virNWFilterDefineXML(no flags) ->
nwfilter callback (0 flag)
Removing the flag argument means that every step along the path has the
same number of arguments, all without having to invent or ignore a 0
flag argument, and without any externally visible changes. And when
mixing an older server with a newer client, or a newer client with an
older server, then the older side will still be passing and ignoring an
extra argument internally, with no change in behavior.
Meanwhile, the only way to use a flags argument is to introduce a new
API; if and when we introduce a new virNWFilterDefineXMLFlags(), we will
also introduce a new RPC call that also preserves that flags argument
over the wire. Whether we then change the driver.h callback to re-add a
flags argument at that time, and share the callback between both APIs,
or whether we have two driver.h callbacks, is a choice we can make at
that time.
>
> ACK
Thanks; I've gone ahead and pushed this (I wrote it on top of Matthias'
generator whitelist patch, and had worried that it might not rebase
well, but thankfully it worked without a hitch).
--
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