On 08/09/2012 09:20 AM, Daniel P. Berrange wrote:
From: "Daniel P. Berrange" <berrange(a)redhat.com>
This adds a 'lockd' lock driver which is just a client which
talks to the lockd daemon to perform all locking. This will
be the default lock driver for any hypervisor which needs one.
* src/Makefile.am: Add lockd.so plugin
* src/locking/lock_driver_lockd.c: Lockd driver impl
Signed-off-by: Daniel P. Berrange <berrange(a)redhat.com>
---
po/POTFILES.in | 1 +
src/Makefile.am | 26 +-
src/locking/lock_driver_lockd.c | 561 ++++++++++++++++++++++++++++++++++++++++
3 files changed, 584 insertions(+), 4 deletions(-)
create mode 100644 src/locking/lock_driver_lockd.c
+++ b/src/locking/lock_driver_lockd.c
@@ -0,0 +1,561 @@
+/*
+ * lock_driver_lockd.c: A lock driver which locks nothing
+ *
+ * Copyright (C) 2010-2011 Red Hat, Inc.
2012
+
+#define VIR_FROM_THIS VIR_FROM_LOCKING
+
+#define virLockError(code, ...) \
+ virReportErrorHelper(VIR_FROM_THIS, code, __FILE__, \
+ __FUNCTION__, __LINE__, __VA_ARGS__)
Rebase this out.
+static const char *
+virLockManagerLockDaemonFindDaemon(void)
+{
+ const char *customDaemon = getenv("VIRTLOCKD_PATH");
+
+ if (customDaemon)
+ return customDaemon;
Is this safe even in the presence of another app linking in libvirt.so
and modifying its own environment? It seems like we might want to
strdup() that into safe static storage to isolate ourselves from future
putenv() nonsense.
+static int virLockManagerLockDaemonDeinit(void)
+{
+ VIR_DEBUG(" ");
Is the empty space just so that you can trace that the function was reached?
+virLockDriver virLockDriverImpl =
+{
+ .version = VIR_LOCK_MANAGER_VERSION,
+ .flags = 0,
+
+ .drvInit = virLockManagerLockDaemonInit,
+ .drvDeinit = virLockManagerLockDaemonDeinit,
Is it worth any /* since 0.10.0 */ comments, in case we later add to
this struct, to know when each callback supported which lock manager
features?
--
Eric Blake eblake(a)redhat.com +1-919-301-3266
Libvirt virtualization library
http://libvirt.org