[libvirt] [PATCH 1/2] Add VIR_TYPED_PARAM_STRING
Eric Blake
eblake at redhat.com
Tue Sep 13 22:30:13 UTC 2011
On 09/12/2011 09:18 AM, Daniel P. Berrange wrote:
>> but I'm quite worried about the on-the-wire compatibility aspect of
>> this change. If a new server sends the new enum value and a string,
>> will the old server that does not know that enum value properly
>> reject the rpc call, or will it cause a crash or other bad things to
>> happen?
>
> If a new server sends a string parameter to an old client, you
> will get a fatal error on the client decoding the XDR data. This
> will cause libvirt to report an XDR decoding error. It (probably)
> isn't fatal, since we've read the entire packet off the wire
> the next RPC call should still work. It is still not too pleasant
> though since old virsh will not work with new libvirtd IIUC,
> so I don't think we can do this without getting a better compat
> story here which does not require changing existing apps like
> virsh.
I agree that things are not fatal, but still not desirable (the old
virsh makes a query but can't get a response, because the new server
sends a string type back that the old virsh has no chance of
understanding). But I think we can solve this by use of a flag (we _do_
have an unsigned int flags argument at our disposal, right?):
virDomainFoo(dom, typed_param_array, len, 0) means "give me back _only_
array values that older libvirt can understand - no strings"
virDomainFoo(dom, typed_param_array, len,
VIR_DOMAIN_FOO_TYPED_STRING_OKAY) means "I'm a newer client, and
understand strings if you send them".
Then newer virsh can be coded to auto-try the new flag value, then fall
back to 0 flags if the flag value was rejected as unknown by older
server; this means that older virsh will not get back string data from
newer servers, but you avoid the issue of erroring out on new
information without being able to get at the old information. This
covers both older->newer and newer->older communications, and means that
only newer->newer with the new flag can take advantage of the new string
parameter.
--
Eric Blake eblake at redhat.com +1-801-349-2682
Libvirt virtualization library http://libvirt.org
More information about the libvir-list
mailing list