[libvirt] [PATCH 2/7] Add virDomainBlockPull support to the remote driver. The generator can handle DomainBlockPullAll and DomainBlockPullAbort. DomainBlockPull and DomainBlockPullInfo must be written by hand.

Matthias Bolte matthias.bolte at googlemail.com
Wed Jun 1 18:35:55 UTC 2011


2011/6/1 Adam Litke <agl at us.ibm.com>:
> On 06/01/2011 12:13 PM, Matthias Bolte wrote:
>> 2011/6/1 Adam Litke <agl at us.ibm.com>:
>>
>> This commit has a pretty long summary line.
>
> Fixed.
>
>>> * src/remote/remote_protocol.x: provide defines for the new entry points
>>> * src/remote/remote_driver.c daemon/remote.c: implement the client and
>>>  server side
>>> * daemon/remote_generator.pl: Specify the manually-written functions
>>>
>>> Signed-off-by: Adam Litke <agl at us.ibm.com>
>>> ---
>>>  daemon/remote.c              |   71 +++++++++++++++++++++++++++++++++++++++++
>>>  daemon/remote_generator.pl   |    8 +++-
>>>  src/remote/remote_driver.c   |   72 +++++++++++++++++++++++++++++++++++++++--
>>>  src/remote/remote_protocol.x |   44 +++++++++++++++++++++++++-
>>>  4 files changed, 188 insertions(+), 7 deletions(-)
>>>
>>> diff --git a/daemon/remote.c b/daemon/remote.c
>>> index 2220655..f6aa78e 100644
>>> --- a/daemon/remote.c
>>> +++ b/daemon/remote.c
>>> @@ -1692,6 +1692,77 @@ no_memory:
>>>     goto cleanup;
>>>  }
>>>
>>> +static int
>>> +remoteDispatchDomainBlockPull(struct qemud_server *server ATTRIBUTE_UNUSED,
>>> +                              struct qemud_client *client ATTRIBUTE_UNUSED,
>>> +                              virConnectPtr conn,
>>> +                              remote_message_header *hdr ATTRIBUTE_UNUSED,
>>> +                              remote_error * rerr,
>>> +                              remote_domain_block_pull_args *args,
>>> +                              remote_domain_block_pull_ret *ret)
>>> +{
>>> +    virDomainPtr dom = NULL;
>>> +    virDomainBlockPullInfo tmp;
>>> +    int rv = -1;
>>> +
>>> +    if (!conn) {
>>> +        virNetError(VIR_ERR_INTERNAL_ERROR, "%s", _("connection not open"));
>>> +        goto cleanup;
>>> +    }
>>> +
>>> +    if (!(dom = get_nonnull_domain(conn, args->dom)))
>>> +        goto cleanup;
>>> +
>>> +    if (virDomainBlockPull(dom, args->path, &tmp, args->flags) < 0)
>>> +        goto cleanup;
>>> +    rv = 0;
>>> +    ret->info.cur = tmp.cur;
>>> +    ret->info.end = tmp.end;
>>> +
>>> +cleanup:
>>> +    if (rv < 0)
>>> +        remoteDispatchError(rerr);
>>> +    if (dom)
>>> +        virDomainFree(dom);
>>> +    return rv;
>>> +}
>>> +
>>> +static int
>>> +remoteDispatchDomainGetBlockPullInfo(struct qemud_server *server ATTRIBUTE_UNUSED,
>>> +                                     struct qemud_client *client ATTRIBUTE_UNUSED,
>>> +                                     virConnectPtr conn,
>>> +                                     remote_message_header *hdr ATTRIBUTE_UNUSED,
>>> +                                     remote_error * rerr,
>>> +                                     remote_domain_get_block_pull_info_args *args,
>>> +                                     remote_domain_get_block_pull_info_ret *ret)
>>> +{
>>> +    virDomainPtr dom = NULL;
>>> +    virDomainBlockPullInfo tmp;
>>> +    int rv = -1;
>>> +
>>> +    if (!conn) {
>>> +        virNetError(VIR_ERR_INTERNAL_ERROR, "%s", _("connection not open"));
>>> +        goto cleanup;
>>> +    }
>>> +
>>> +    if (!(dom = get_nonnull_domain(conn, args->dom)))
>>> +        goto cleanup;
>>> +
>>> +    if (virDomainGetBlockPullInfo(dom, args->path, &tmp, args->flags) < 0)
>>> +        goto cleanup;
>>> +    rv = 0;
>>> +    ret->info.cur = tmp.cur;
>>> +    ret->info.end = tmp.end;
>>> +
>>> +cleanup:
>>> +    if (rv < 0)
>>> +        remoteDispatchError(rerr);
>>> +    if (dom)
>>> +        virDomainFree(dom);
>>> +    return rv;
>>> +}
>>
>> The generator should be able to deal with this. I might have to tweak
>> it to handle multi-return-value procedures more general.
>
> That would be excellent.  I am not doing anything particularly special.

Yes works almost fine. I've attached a patch for the generator to deal
with the placement of the struct in the signature.

>>>  struct remote_num_of_networks_ret {
>>> @@ -2176,7 +2213,12 @@ enum remote_procedure {
>>>     REMOTE_PROC_DOMAIN_GET_BLKIO_PARAMETERS = 206,
>>>     REMOTE_PROC_DOMAIN_MIGRATE_SET_MAX_SPEED = 207,
>>>     REMOTE_PROC_STORAGE_VOL_UPLOAD = 208,
>>> -    REMOTE_PROC_STORAGE_VOL_DOWNLOAD = 209
>>> +    REMOTE_PROC_STORAGE_VOL_DOWNLOAD = 209,
>>> +    REMOTE_PROC_DOMAIN_BLOCK_PULL = 210,
>>> +
>>> +    REMOTE_PROC_DOMAIN_BLOCK_PULL_ALL = 211,
>>> +    REMOTE_PROC_DOMAIN_BLOCK_PULL_ABORT = 212,
>>> +    REMOTE_PROC_DOMAIN_GET_BLOCK_PULL_INFO = 213
>>
>> Annotations for the generator go here.
>
> I am not sure what you mean by annotations for the generator.  Could you
> explain further?

Instead of the blacklist in the generator each procedure has a comment
that tells the generator how to handle it. It's explained in the .x
file.

>> I also miss corresponding updates to src/remote_protocol-structs.
>
> Isn't this file generated from remote-protocol.x?  It seems to have
> exactly the same information.

This file is not generated, it is used to verify that the existing XDR
protocol is not changed, but only extended. When you have pdwtags
installed the make check will verify this.

Matthias
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0001-remote-generator-Handle-virDomainGetBlockPullInfo.patch
Type: text/x-patch
Size: 1970 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/libvir-list/attachments/20110601/6ebfac6f/attachment-0001.bin>


More information about the libvir-list mailing list