[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

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


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]