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@redhat.com +1-801-349-2682 Libvirt virtualization library http://libvirt.org