2011/6/1 Adam Litke <agl@us.ibm.com>:
* 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@us.ibm.com> ---
From the generator point-of-view I would want to avoid having the info
+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; +} parameter being NULLable, as this differs from the common pattern and results in special case code in the generator.
+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; }; Matthias