[libvirt] [PATCHv5 1/3] API: add VIR_TYPED_PARAM_STRING

[Eric Blake]

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