2015-10-15 12:48:58 +00:00
|
|
|
/*
|
|
|
|
* admin_remote.c
|
|
|
|
*
|
|
|
|
* Copyright (C) 2015 Red Hat, Inc.
|
|
|
|
*
|
|
|
|
* This library is free software; you can redistribute it and/or
|
|
|
|
* modify it under the terms of the GNU Lesser General Public
|
|
|
|
* License as published by the Free Software Foundation; either
|
|
|
|
* version 2.1 of the License, or (at your option) any later version.
|
|
|
|
*
|
|
|
|
* This library is distributed in the hope that it will be useful,
|
|
|
|
* but WITHOUT ANY WARRANTY; without even the implied warranty of
|
|
|
|
* MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
|
|
|
|
* Lesser General Public License for more details.
|
|
|
|
*
|
|
|
|
* You should have received a copy of the GNU Lesser General Public
|
|
|
|
* License along with this library. If not, see
|
|
|
|
* <http://www.gnu.org/licenses/>.
|
|
|
|
*
|
|
|
|
* Author: Erik Skultety <eskultet@redhat.com>
|
|
|
|
*/
|
|
|
|
|
|
|
|
#include <config.h>
|
|
|
|
#include <rpc/rpc.h>
|
|
|
|
#include "admin_protocol.h"
|
|
|
|
|
|
|
|
typedef struct _remoteAdminPriv remoteAdminPriv;
|
|
|
|
typedef remoteAdminPriv *remoteAdminPrivPtr;
|
|
|
|
|
|
|
|
struct _remoteAdminPriv {
|
|
|
|
virObjectLockable parent;
|
|
|
|
|
|
|
|
int counter;
|
|
|
|
virNetClientPtr client;
|
|
|
|
virNetClientProgramPtr program;
|
|
|
|
};
|
|
|
|
|
|
|
|
static virClassPtr remoteAdminPrivClass;
|
|
|
|
|
|
|
|
static void
|
|
|
|
remoteAdminPrivDispose(void *opaque)
|
|
|
|
{
|
|
|
|
remoteAdminPrivPtr priv = opaque;
|
|
|
|
|
|
|
|
virObjectUnref(priv->program);
|
|
|
|
virObjectUnref(priv->client);
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
|
|
static int
|
admin: Rename virAdmConnect to virAdmDaemon
virAdmConnect was named after virConnect, but after some discussions,
most of the APIs called will be working with remote daemon and starting
them virAdmDaemon will make more sense. Only possibly controversal name
is CloseCallback (de)registration, and connecting to the daemon (which
will still be Open/Close), but even this makes sense if one thinks about
the daemon being opened and closed, e.g. as file, etc.
This way all the APIs working with the daemon will start with
virAdmDaemon prefix, they will accept virAdmDaemonPtr as first parameter
and that will better suit with other namings as well (virDomain*,
virAdmServer*, etc.).
Because in virt-admin, the connection name does not refer to a struct
that would have a connect in its name, also adjust 'connname' in
clients. And because it is not used anywhere in the vsh code, move it
from there into each client.
Signed-off-by: Martin Kletzander <mkletzan@redhat.com>
2015-11-25 15:59:30 +00:00
|
|
|
callFull(virAdmDaemonPtr dmn ATTRIBUTE_UNUSED,
|
2015-10-15 12:48:58 +00:00
|
|
|
remoteAdminPrivPtr priv,
|
|
|
|
int *fdin,
|
|
|
|
size_t fdinlen,
|
|
|
|
int **fdout,
|
|
|
|
size_t *fdoutlen,
|
|
|
|
int proc_nr,
|
|
|
|
xdrproc_t args_filter, char *args,
|
|
|
|
xdrproc_t ret_filter, char *ret)
|
|
|
|
{
|
|
|
|
int rv;
|
|
|
|
virNetClientProgramPtr prog = priv->program;
|
|
|
|
int counter = priv->counter++;
|
|
|
|
virNetClientPtr client = priv->client;
|
|
|
|
|
|
|
|
/* Unlock, so that if we get any async events/stream data
|
|
|
|
* while processing the RPC, we don't deadlock when our
|
|
|
|
* callbacks for those are invoked
|
|
|
|
*/
|
|
|
|
virObjectRef(priv);
|
|
|
|
virObjectUnlock(priv);
|
|
|
|
|
|
|
|
rv = virNetClientProgramCall(prog,
|
|
|
|
client,
|
|
|
|
counter,
|
|
|
|
proc_nr,
|
|
|
|
fdinlen, fdin,
|
|
|
|
fdoutlen, fdout,
|
|
|
|
args_filter, args,
|
|
|
|
ret_filter, ret);
|
|
|
|
|
|
|
|
virObjectLock(priv);
|
|
|
|
virObjectUnref(priv);
|
|
|
|
|
|
|
|
return rv;
|
|
|
|
}
|
|
|
|
|
|
|
|
static int
|
admin: Rename virAdmConnect to virAdmDaemon
virAdmConnect was named after virConnect, but after some discussions,
most of the APIs called will be working with remote daemon and starting
them virAdmDaemon will make more sense. Only possibly controversal name
is CloseCallback (de)registration, and connecting to the daemon (which
will still be Open/Close), but even this makes sense if one thinks about
the daemon being opened and closed, e.g. as file, etc.
This way all the APIs working with the daemon will start with
virAdmDaemon prefix, they will accept virAdmDaemonPtr as first parameter
and that will better suit with other namings as well (virDomain*,
virAdmServer*, etc.).
Because in virt-admin, the connection name does not refer to a struct
that would have a connect in its name, also adjust 'connname' in
clients. And because it is not used anywhere in the vsh code, move it
from there into each client.
Signed-off-by: Martin Kletzander <mkletzan@redhat.com>
2015-11-25 15:59:30 +00:00
|
|
|
call(virAdmDaemonPtr dmn,
|
2015-10-15 12:48:58 +00:00
|
|
|
unsigned int flags,
|
|
|
|
int proc_nr,
|
|
|
|
xdrproc_t args_filter, char *args,
|
|
|
|
xdrproc_t ret_filter, char *ret)
|
|
|
|
{
|
|
|
|
virCheckFlags(0, -1);
|
|
|
|
|
admin: Rename virAdmConnect to virAdmDaemon
virAdmConnect was named after virConnect, but after some discussions,
most of the APIs called will be working with remote daemon and starting
them virAdmDaemon will make more sense. Only possibly controversal name
is CloseCallback (de)registration, and connecting to the daemon (which
will still be Open/Close), but even this makes sense if one thinks about
the daemon being opened and closed, e.g. as file, etc.
This way all the APIs working with the daemon will start with
virAdmDaemon prefix, they will accept virAdmDaemonPtr as first parameter
and that will better suit with other namings as well (virDomain*,
virAdmServer*, etc.).
Because in virt-admin, the connection name does not refer to a struct
that would have a connect in its name, also adjust 'connname' in
clients. And because it is not used anywhere in the vsh code, move it
from there into each client.
Signed-off-by: Martin Kletzander <mkletzan@redhat.com>
2015-11-25 15:59:30 +00:00
|
|
|
return callFull(dmn, dmn->privateData,
|
2015-10-15 12:48:58 +00:00
|
|
|
NULL, 0, NULL, NULL, proc_nr,
|
|
|
|
args_filter, args, ret_filter, ret);
|
|
|
|
}
|
|
|
|
|
|
|
|
#include "admin_client.h"
|
|
|
|
|
2015-10-12 15:10:57 +00:00
|
|
|
static void
|
|
|
|
remoteAdminClientCloseFunc(virNetClientPtr client ATTRIBUTE_UNUSED,
|
|
|
|
int reason,
|
|
|
|
void *opaque)
|
|
|
|
{
|
admin: Rename virAdmConnect to virAdmDaemon
virAdmConnect was named after virConnect, but after some discussions,
most of the APIs called will be working with remote daemon and starting
them virAdmDaemon will make more sense. Only possibly controversal name
is CloseCallback (de)registration, and connecting to the daemon (which
will still be Open/Close), but even this makes sense if one thinks about
the daemon being opened and closed, e.g. as file, etc.
This way all the APIs working with the daemon will start with
virAdmDaemon prefix, they will accept virAdmDaemonPtr as first parameter
and that will better suit with other namings as well (virDomain*,
virAdmServer*, etc.).
Because in virt-admin, the connection name does not refer to a struct
that would have a connect in its name, also adjust 'connname' in
clients. And because it is not used anywhere in the vsh code, move it
from there into each client.
Signed-off-by: Martin Kletzander <mkletzan@redhat.com>
2015-11-25 15:59:30 +00:00
|
|
|
virAdmDaemonCloseCallbackDataPtr cbdata = opaque;
|
2015-10-12 15:10:57 +00:00
|
|
|
|
|
|
|
virObjectLock(cbdata);
|
|
|
|
|
|
|
|
if (cbdata->callback) {
|
|
|
|
VIR_DEBUG("Triggering connection close callback %p reason=%d, opaque=%p",
|
|
|
|
cbdata->callback, reason, cbdata->opaque);
|
admin: Rename virAdmConnect to virAdmDaemon
virAdmConnect was named after virConnect, but after some discussions,
most of the APIs called will be working with remote daemon and starting
them virAdmDaemon will make more sense. Only possibly controversal name
is CloseCallback (de)registration, and connecting to the daemon (which
will still be Open/Close), but even this makes sense if one thinks about
the daemon being opened and closed, e.g. as file, etc.
This way all the APIs working with the daemon will start with
virAdmDaemon prefix, they will accept virAdmDaemonPtr as first parameter
and that will better suit with other namings as well (virDomain*,
virAdmServer*, etc.).
Because in virt-admin, the connection name does not refer to a struct
that would have a connect in its name, also adjust 'connname' in
clients. And because it is not used anywhere in the vsh code, move it
from there into each client.
Signed-off-by: Martin Kletzander <mkletzan@redhat.com>
2015-11-25 15:59:30 +00:00
|
|
|
cbdata->callback(cbdata->dmn, reason, cbdata->opaque);
|
2015-10-12 15:10:57 +00:00
|
|
|
|
|
|
|
if (cbdata->freeCallback)
|
|
|
|
cbdata->freeCallback(cbdata->opaque);
|
|
|
|
cbdata->callback = NULL;
|
|
|
|
cbdata->freeCallback = NULL;
|
|
|
|
}
|
|
|
|
virObjectUnlock(cbdata);
|
|
|
|
}
|
|
|
|
|
2015-10-12 15:08:29 +00:00
|
|
|
static int
|
admin: Rename virAdmConnect to virAdmDaemon
virAdmConnect was named after virConnect, but after some discussions,
most of the APIs called will be working with remote daemon and starting
them virAdmDaemon will make more sense. Only possibly controversal name
is CloseCallback (de)registration, and connecting to the daemon (which
will still be Open/Close), but even this makes sense if one thinks about
the daemon being opened and closed, e.g. as file, etc.
This way all the APIs working with the daemon will start with
virAdmDaemon prefix, they will accept virAdmDaemonPtr as first parameter
and that will better suit with other namings as well (virDomain*,
virAdmServer*, etc.).
Because in virt-admin, the connection name does not refer to a struct
that would have a connect in its name, also adjust 'connname' in
clients. And because it is not used anywhere in the vsh code, move it
from there into each client.
Signed-off-by: Martin Kletzander <mkletzan@redhat.com>
2015-11-25 15:59:30 +00:00
|
|
|
remoteAdminDaemonOpen(virAdmDaemonPtr dmn, unsigned int flags)
|
2015-10-12 15:08:29 +00:00
|
|
|
{
|
|
|
|
int rv = -1;
|
admin: Rename virAdmConnect to virAdmDaemon
virAdmConnect was named after virConnect, but after some discussions,
most of the APIs called will be working with remote daemon and starting
them virAdmDaemon will make more sense. Only possibly controversal name
is CloseCallback (de)registration, and connecting to the daemon (which
will still be Open/Close), but even this makes sense if one thinks about
the daemon being opened and closed, e.g. as file, etc.
This way all the APIs working with the daemon will start with
virAdmDaemon prefix, they will accept virAdmDaemonPtr as first parameter
and that will better suit with other namings as well (virDomain*,
virAdmServer*, etc.).
Because in virt-admin, the connection name does not refer to a struct
that would have a connect in its name, also adjust 'connname' in
clients. And because it is not used anywhere in the vsh code, move it
from there into each client.
Signed-off-by: Martin Kletzander <mkletzan@redhat.com>
2015-11-25 15:59:30 +00:00
|
|
|
remoteAdminPrivPtr priv = dmn->privateData;
|
|
|
|
admin_daemon_open_args args;
|
2015-10-12 15:08:29 +00:00
|
|
|
|
|
|
|
virObjectLock(priv);
|
|
|
|
|
|
|
|
args.flags = flags;
|
|
|
|
|
2015-10-12 15:10:57 +00:00
|
|
|
if (virNetClientRegisterAsyncIO(priv->client) < 0) {
|
|
|
|
VIR_DEBUG("Failed to add event watch, disabling events and support for"
|
|
|
|
" keepalive messages");
|
|
|
|
virResetLastError();
|
|
|
|
}
|
|
|
|
|
admin: Rename virAdmConnect to virAdmDaemon
virAdmConnect was named after virConnect, but after some discussions,
most of the APIs called will be working with remote daemon and starting
them virAdmDaemon will make more sense. Only possibly controversal name
is CloseCallback (de)registration, and connecting to the daemon (which
will still be Open/Close), but even this makes sense if one thinks about
the daemon being opened and closed, e.g. as file, etc.
This way all the APIs working with the daemon will start with
virAdmDaemon prefix, they will accept virAdmDaemonPtr as first parameter
and that will better suit with other namings as well (virDomain*,
virAdmServer*, etc.).
Because in virt-admin, the connection name does not refer to a struct
that would have a connect in its name, also adjust 'connname' in
clients. And because it is not used anywhere in the vsh code, move it
from there into each client.
Signed-off-by: Martin Kletzander <mkletzan@redhat.com>
2015-11-25 15:59:30 +00:00
|
|
|
virObjectRef(dmn->closeCallback);
|
2015-10-12 15:10:57 +00:00
|
|
|
virNetClientSetCloseCallback(priv->client, remoteAdminClientCloseFunc,
|
admin: Rename virAdmConnect to virAdmDaemon
virAdmConnect was named after virConnect, but after some discussions,
most of the APIs called will be working with remote daemon and starting
them virAdmDaemon will make more sense. Only possibly controversal name
is CloseCallback (de)registration, and connecting to the daemon (which
will still be Open/Close), but even this makes sense if one thinks about
the daemon being opened and closed, e.g. as file, etc.
This way all the APIs working with the daemon will start with
virAdmDaemon prefix, they will accept virAdmDaemonPtr as first parameter
and that will better suit with other namings as well (virDomain*,
virAdmServer*, etc.).
Because in virt-admin, the connection name does not refer to a struct
that would have a connect in its name, also adjust 'connname' in
clients. And because it is not used anywhere in the vsh code, move it
from there into each client.
Signed-off-by: Martin Kletzander <mkletzan@redhat.com>
2015-11-25 15:59:30 +00:00
|
|
|
dmn->closeCallback,
|
2015-10-12 15:10:57 +00:00
|
|
|
virObjectFreeCallback);
|
|
|
|
|
admin: Rename virAdmConnect to virAdmDaemon
virAdmConnect was named after virConnect, but after some discussions,
most of the APIs called will be working with remote daemon and starting
them virAdmDaemon will make more sense. Only possibly controversal name
is CloseCallback (de)registration, and connecting to the daemon (which
will still be Open/Close), but even this makes sense if one thinks about
the daemon being opened and closed, e.g. as file, etc.
This way all the APIs working with the daemon will start with
virAdmDaemon prefix, they will accept virAdmDaemonPtr as first parameter
and that will better suit with other namings as well (virDomain*,
virAdmServer*, etc.).
Because in virt-admin, the connection name does not refer to a struct
that would have a connect in its name, also adjust 'connname' in
clients. And because it is not used anywhere in the vsh code, move it
from there into each client.
Signed-off-by: Martin Kletzander <mkletzan@redhat.com>
2015-11-25 15:59:30 +00:00
|
|
|
if (call(dmn, 0, ADMIN_PROC_DAEMON_OPEN,
|
|
|
|
(xdrproc_t)xdr_admin_daemon_open_args, (char *)&args,
|
2015-10-12 15:08:29 +00:00
|
|
|
(xdrproc_t)xdr_void, (char *)NULL) == -1) {
|
|
|
|
goto done;
|
|
|
|
}
|
|
|
|
|
|
|
|
rv = 0;
|
|
|
|
|
|
|
|
done:
|
|
|
|
virObjectUnlock(priv);
|
|
|
|
return rv;
|
|
|
|
}
|
|
|
|
|
|
|
|
static int
|
admin: Rename virAdmConnect to virAdmDaemon
virAdmConnect was named after virConnect, but after some discussions,
most of the APIs called will be working with remote daemon and starting
them virAdmDaemon will make more sense. Only possibly controversal name
is CloseCallback (de)registration, and connecting to the daemon (which
will still be Open/Close), but even this makes sense if one thinks about
the daemon being opened and closed, e.g. as file, etc.
This way all the APIs working with the daemon will start with
virAdmDaemon prefix, they will accept virAdmDaemonPtr as first parameter
and that will better suit with other namings as well (virDomain*,
virAdmServer*, etc.).
Because in virt-admin, the connection name does not refer to a struct
that would have a connect in its name, also adjust 'connname' in
clients. And because it is not used anywhere in the vsh code, move it
from there into each client.
Signed-off-by: Martin Kletzander <mkletzan@redhat.com>
2015-11-25 15:59:30 +00:00
|
|
|
remoteAdminDaemonClose(virAdmDaemonPtr dmn)
|
2015-10-12 15:08:29 +00:00
|
|
|
{
|
|
|
|
int rv = -1;
|
admin: Rename virAdmConnect to virAdmDaemon
virAdmConnect was named after virConnect, but after some discussions,
most of the APIs called will be working with remote daemon and starting
them virAdmDaemon will make more sense. Only possibly controversal name
is CloseCallback (de)registration, and connecting to the daemon (which
will still be Open/Close), but even this makes sense if one thinks about
the daemon being opened and closed, e.g. as file, etc.
This way all the APIs working with the daemon will start with
virAdmDaemon prefix, they will accept virAdmDaemonPtr as first parameter
and that will better suit with other namings as well (virDomain*,
virAdmServer*, etc.).
Because in virt-admin, the connection name does not refer to a struct
that would have a connect in its name, also adjust 'connname' in
clients. And because it is not used anywhere in the vsh code, move it
from there into each client.
Signed-off-by: Martin Kletzander <mkletzan@redhat.com>
2015-11-25 15:59:30 +00:00
|
|
|
remoteAdminPrivPtr priv = dmn->privateData;
|
2015-10-12 15:08:29 +00:00
|
|
|
|
|
|
|
virObjectLock(priv);
|
|
|
|
|
admin: Rename virAdmConnect to virAdmDaemon
virAdmConnect was named after virConnect, but after some discussions,
most of the APIs called will be working with remote daemon and starting
them virAdmDaemon will make more sense. Only possibly controversal name
is CloseCallback (de)registration, and connecting to the daemon (which
will still be Open/Close), but even this makes sense if one thinks about
the daemon being opened and closed, e.g. as file, etc.
This way all the APIs working with the daemon will start with
virAdmDaemon prefix, they will accept virAdmDaemonPtr as first parameter
and that will better suit with other namings as well (virDomain*,
virAdmServer*, etc.).
Because in virt-admin, the connection name does not refer to a struct
that would have a connect in its name, also adjust 'connname' in
clients. And because it is not used anywhere in the vsh code, move it
from there into each client.
Signed-off-by: Martin Kletzander <mkletzan@redhat.com>
2015-11-25 15:59:30 +00:00
|
|
|
if (call(dmn, 0, ADMIN_PROC_DAEMON_CLOSE,
|
2015-10-12 15:08:29 +00:00
|
|
|
(xdrproc_t)xdr_void, (char *)NULL,
|
|
|
|
(xdrproc_t)xdr_void, (char *)NULL) == -1) {
|
|
|
|
goto done;
|
|
|
|
}
|
|
|
|
|
2015-10-12 15:10:57 +00:00
|
|
|
virNetClientSetCloseCallback(priv->client, NULL, NULL, NULL);
|
|
|
|
|
2015-10-12 15:08:29 +00:00
|
|
|
rv = 0;
|
|
|
|
|
|
|
|
done:
|
|
|
|
virObjectUnlock(priv);
|
|
|
|
return rv;
|
|
|
|
}
|
|
|
|
|
2015-10-15 12:48:58 +00:00
|
|
|
static void
|
|
|
|
remoteAdminPrivFree(void *opaque)
|
|
|
|
{
|
admin: Rename virAdmConnect to virAdmDaemon
virAdmConnect was named after virConnect, but after some discussions,
most of the APIs called will be working with remote daemon and starting
them virAdmDaemon will make more sense. Only possibly controversal name
is CloseCallback (de)registration, and connecting to the daemon (which
will still be Open/Close), but even this makes sense if one thinks about
the daemon being opened and closed, e.g. as file, etc.
This way all the APIs working with the daemon will start with
virAdmDaemon prefix, they will accept virAdmDaemonPtr as first parameter
and that will better suit with other namings as well (virDomain*,
virAdmServer*, etc.).
Because in virt-admin, the connection name does not refer to a struct
that would have a connect in its name, also adjust 'connname' in
clients. And because it is not used anywhere in the vsh code, move it
from there into each client.
Signed-off-by: Martin Kletzander <mkletzan@redhat.com>
2015-11-25 15:59:30 +00:00
|
|
|
virAdmDaemonPtr dmn = opaque;
|
2015-10-15 12:48:58 +00:00
|
|
|
|
admin: Rename virAdmConnect to virAdmDaemon
virAdmConnect was named after virConnect, but after some discussions,
most of the APIs called will be working with remote daemon and starting
them virAdmDaemon will make more sense. Only possibly controversal name
is CloseCallback (de)registration, and connecting to the daemon (which
will still be Open/Close), but even this makes sense if one thinks about
the daemon being opened and closed, e.g. as file, etc.
This way all the APIs working with the daemon will start with
virAdmDaemon prefix, they will accept virAdmDaemonPtr as first parameter
and that will better suit with other namings as well (virDomain*,
virAdmServer*, etc.).
Because in virt-admin, the connection name does not refer to a struct
that would have a connect in its name, also adjust 'connname' in
clients. And because it is not used anywhere in the vsh code, move it
from there into each client.
Signed-off-by: Martin Kletzander <mkletzan@redhat.com>
2015-11-25 15:59:30 +00:00
|
|
|
remoteAdminDaemonClose(dmn);
|
|
|
|
virObjectUnref(dmn->privateData);
|
2015-10-15 12:48:58 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
static remoteAdminPrivPtr
|
|
|
|
remoteAdminPrivNew(const char *sock_path)
|
|
|
|
{
|
|
|
|
remoteAdminPrivPtr priv = NULL;
|
|
|
|
|
|
|
|
if (!(priv = virObjectLockableNew(remoteAdminPrivClass)))
|
|
|
|
goto error;
|
|
|
|
|
|
|
|
if (!(priv->client = virNetClientNewUNIX(sock_path, false, NULL)))
|
|
|
|
goto error;
|
|
|
|
|
|
|
|
if (!(priv->program = virNetClientProgramNew(ADMIN_PROGRAM,
|
|
|
|
ADMIN_PROTOCOL_VERSION,
|
|
|
|
NULL, 0, NULL)))
|
|
|
|
goto error;
|
|
|
|
|
|
|
|
if (virNetClientAddProgram(priv->client, priv->program) < 0)
|
|
|
|
goto error;
|
|
|
|
|
|
|
|
return priv;
|
|
|
|
error:
|
|
|
|
virObjectUnref(priv);
|
|
|
|
return NULL;
|
|
|
|
}
|