Re: [libvirt] [PATCH v1 12/23] virtlockd: Work virSeclabelSpace in
On 16.10.2015 09:32, Peter Krempa wrote:
On Mon, Oct 12, 2015 at 12:25:57 +0200, Michal Privoznik wrote:
A rather sparse commit message.
> Signed-off-by: Michal Privoznik <mprivozn(a)redhat.com>
> ---
> src/locking/lock_daemon.c | 44 ++++++++++++++++++++++++++
> src/locking/lock_daemon.h | 8 +++++
> src/locking/lock_daemon_dispatch.c | 65 ++++++++++++++++++++++++++++++++------
> 3 files changed, 108 insertions(+), 9 deletions(-)
[...]
> diff --git a/src/locking/lock_daemon_dispatch.c b/src/locking/lock_daemon_dispatch.c
> index 2d0bd81..5ad7e11 100644
> --- a/src/locking/lock_daemon_dispatch.c
> +++ b/src/locking/lock_daemon_dispatch.c
[...]
> @@ -433,21 +435,66 @@ virLockSpaceProtocolDispatchCreateLockSpace(virNetServerPtr
server ATTRIBUTE_UNU
[...]
> static int
> virLockSpaceProtocolDispatchRecallSeclabel(virNetServerPtr server ATTRIBUTE_UNUSED,
> - virNetServerClientPtr client
ATTRIBUTE_UNUSED,
> + virNetServerClientPtr client,
> virNetMessagePtr msg ATTRIBUTE_UNUSED,
> - virNetMessageErrorPtr rerr
ATTRIBUTE_UNUSED,
> - virLockSpaceProtocolRecallSeclabelArgs
*args ATTRIBUTE_UNUSED,
> - virLockSpaceProtocolRecallSeclabelRet
*ret ATTRIBUTE_UNUSED)
> + virNetMessageErrorPtr rerr,
> + virLockSpaceProtocolRecallSeclabelArgs
*args,
> + virLockSpaceProtocolRecallSeclabelRet
*ret)
> {
> - return 0;
> + int rv = -1;
> + int funcRet;
> + virLockDaemonClientPtr priv =
> + virNetServerClientGetPrivateData(client);
> + char *label = NULL;
> + char **label_p = NULL;
> +
> + virMutexLock(&priv->lock);
> +
> + memset(ret, 0, sizeof(*ret));
> +
> + funcRet = virLockDaemonRecallSeclabel(lockDaemon,
> + args->path, args->model,
&label);
> +
> + if (funcRet == 0 &&
> + (VIR_ALLOC(label_p) < 0 ||
> + VIR_STRDUP(*label_p, label) < 0))
This looks rather weird? Why is the extra pointer necessary?
It's due to way we handle remote strings. If that was remote NON NULL
string, then a single pointer would be enough, but since I want it to be
NULL sometimes I must do it this way. If you look at the remote
procedures we generate automatically you'll find the same pattern (in
fact I've copied the idea from there).
Michal