Re: [libvirt] [PATCHv5 1/3] API: add VIR_TYPED_PARAM_STRING
On 11/01/2011 05:47 PM, Eric Blake wrote:
This allows strings to be transported between client and server
in the context of name-type-value virTypedParameter functions.
For compatibility,
o new clients will not send strings to old servers, based on
a feature check
o new servers will not send strings to old clients without the
flag VIR_TYPED_PARAM_STRING_OKAY; this is enforced by
libvirt.c, so that drivers need not worry about it
o the flag VIR_TYPED_PARAM_STRING_OKAY is set automatically,
based on a feature check (so far, no driver implements it),
so clients do not have to worry about it
Future patches can then enable the feature on a per-driver basis.
Now that I've finally got blkiotune passing strings coded up, I found
out my back-compat rules above didn't quite work; I'll have to fix it in
v6. Basically, we have the following call chains when using qemu:
new virsh
virDomainGetBlkioParameters on client
probe for feature in rpc driver
makes rpc call, remote server supports it
driver callback with STRING_OKAY flag to rpc driver
makes rpc call
virDomainGetBlkioParameters on server
probe for feature in qemu driver
flag already set
makes driver call with STRING_OKAY flag
filter has nothing to remove
rpc call returns string
filter has nothing to remove
success, virsh sees string param
old virsh
virDomainGetBlkioParameters on client
driver callback without STRING_OKAY flag to rpc driver
makes rpc call
virDomainGetBlkioParameters on server
probe for feature in qemu driver
flag was clear, now gets set
makes driver call with STRING_OKAY flag
filter has nothing to remove
rpc call returns string
not expecting string, rpc rejects reply
virsh sees error
So, while libvirt.c can auto-add the flag, the filtering should be done
in the rpc return code, rather than in libvirt.c. That is, libvirt.c
doesn't know whether it is being called by a local client (which means
the client was compiled against new enough headers and supports the
returned string) or a remote client (in which case
virDomainGetBlkioParameters was called by the rpc code, so the rpc code
knows whether the remote client passed the flag, but libvirt.c always
sees the flag set). The corrected call chains will look like:
new virsh
virDomainGetBlkioParameters on client
probe for feature in rpc driver
makes rpc call, remote server supports it
driver callback with STRING_OKAY flag to rpc driver
makes rpc call
virDomainGetBlkioParameters on server
probe for feature in qemu driver
flag already set
makes driver call with STRING_OKAY flag
rpc call saw flag set on entry, so it returns string
rpc client unpacks string
success, virsh sees string param
old virsh
virDomainGetBlkioParameters on client
driver callback without STRING_OKAY flag to rpc driver
makes rpc call
virDomainGetBlkioParameters on server
probe for feature in qemu driver
flag was clear, now gets set
makes driver call with STRING_OKAY flag
rpc call saw flag clear on entry, filters string
rpc client does not have to deal with stringrpc rejects reply
success, virsh does not see string param
--
Eric Blake eblake(a)redhat.com +1-801-349-2682
Libvirt virtualization library http://libvirt.org