2011/6/1 Adam Litke <agl@xxxxxxxxxx>:
> On 06/01/2011 12:27 PM, Matthias Bolte wrote:
>> 2011/6/1 Adam Litke <agl@xxxxxxxxxx>:
>>> * 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@xxxxxxxxxx>
>>> ---
>>
>> +static int remoteDomainBlockPull(virDomainPtr domain,
>> + Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â const char *path,
>> + Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â virDomainBlockPullInfoPtr info,
>> + Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â unsigned int flags)
>> +{
>> + Â Âint rv = -1;
>> + Â Âremote_domain_block_pull_args args;
>> + Â Âremote_domain_block_pull_ret ret;
>> + Â Âstruct private_data *priv = domain->conn->privateData;
>> +
>> + Â ÂremoteDriverLock(priv);
>> +
>> + Â Âmake_nonnull_domain(&args.dom, domain);
>> + Â Âargs.path = (char *)path;
>> + Â Âargs.flags = flags;
>> +
>> + Â Âif (call(domain->conn, priv, 0, REMOTE_PROC_DOMAIN_BLOCK_PULL,
>> + Â Â Â Â Â Â (xdrproc_t)xdr_remote_domain_block_pull_args, (char *)&args,
>> + Â Â Â Â Â Â (xdrproc_t)xdr_remote_domain_block_pull_ret, (char *)&ret) == -1)
>> + Â Â Â Âgoto done;
>> +
>> + Â Âif (info) {
>> + Â Â Â Âinfo->cur = ret.info.cur;
>> + Â Â Â Âinfo->end = ret.info.end;
>> + Â Â}
>> + Â Ârv = 0;
>> +
>> +done:
>> + Â ÂremoteDriverUnlock(priv);
>> + Â Âreturn rv;
>> +}
>>
>> From the generator point-of-view I would want to avoid having the info
>> parameter being NULLable, as this differs from the common pattern and
>> results in special case code in the generator.
>
> From an API user's point of view, I think it's nice to allow NULL for
> the info struct. ÂThe user may not care about the current progress
> information. ÂI could fix this at the global libvirt level by allocating
> a dummy struct to pass down to the driver implementations if the user
> passed NULL. ÂWould that be acceptable?
No, don't make runtime compromises to simplify the generator, we can
special case this later.
>>> +struct remote_domain_block_pull_info {
>>> + Â Âunsigned hyper cur;
>>> + Â Âunsigned hyper end;
>>> +};
>>
>>> +struct remote_domain_block_pull_ret {
>>> + Â Âremote_domain_block_pull_info info;
>>> +};
>>
>>> +struct remote_domain_get_block_pull_info_ret {
>>> + Â Âremote_domain_block_pull_info info;
>>> +};
>>
>> From the generator point-of-view I would avoid this approach of
>> putting a struct in a struct because that differs from the common
>> approach and results in special case code in the generator. It should
>> look like this
>>
>> struct remote_domain_block_pull_ret {
>> Â Â unsigned hyper cur;
>> Â Â unsigned hyper end;
>> };
>>
>> struct remote_domain_get_block_pull_info_ret {
>> Â Â unsigned hyper cur;
>> Â Â unsigned hyper end;
>> };
>
> Ok, I will make this change.
>
The patch from my other response require this change and makes the
generator deal with the virDomainGetBlockPullInfo. virDomainBlockPull
requires some additional special case for the optional struct so you
should just keep that one manually written and we'll deal with that
later.
Matthias
--
libvir-list mailing list
libvir-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/libvir-list