Displaying 9 results from an estimated 9 matches for "optional_stub".
2020 Jun 02
0
[PATCH nbdkit 4/5] tests: Enhance dummy-vddk.
...s don't
- * need to do anything.
- */
+/* This file pretends to be libvixDiskLib.so.6. */
#include <stdio.h>
#include <stdlib.h>
#include <stdint.h>
+#include <string.h>
#include "vddk-structs.h"
+#define STUB(fn,ret,args) extern ret fn args;
+#define OPTIONAL_STUB(fn,ret,args)
+#include "vddk-stubs.h"
+#undef STUB
+#undef OPTIONAL_STUB
+
+#define CAPACITY 1024 /* sectors */
+static char disk[CAPACITY * VIXDISKLIB_SECTOR_SIZE];
+
VixError
VixDiskLib_InitEx (uint32_t major, uint32_t minor,
VixDiskLibGenericLogFunc *log_function,...
2019 Oct 10
1
[PATCH NOT WORKING nbdkit] vddk: Restructure plugin to allow greater parallelism.
We had a query yesterday about the VDDK plugin and making it actually
obey the weird "Multithreading Considerations" rules in the VDDK
documentation
(https://vdc-download.vmware.com/vmwb-repository/dcr-public/8f96698a-0e7b-4d67-bb6c-d18a1d101540/ef536a47-27cd-481a-90ef-76b38e75353c/vsphere-vddk-671-programming-guide.pdf)
This patch is my attempt to implement this.
The idea is that the
2020 Feb 13
4
[PATCH nbdkit v2 2/3] NOT WORKING: vddk: Drive library loading from libdir parameter.
I couldn't get this to work in the end. This is the latest
non-working version. This email documents what doesn't work for the
permanent record.
The central problem is that VDDK InitEx() appears to dlopen() various
of its own plugins. Although I wasn't able to capture exactly what
dlopen() command it is running, the plugins cannot be loaded because
they rely on the recompiled
2020 Feb 13
2
[PATCH nbdkit 1/2] vddk: Delay loading VDDK until config_complete.
...("required VDDK symbol \"%s\" is missing: %s", \
- #fn, dlerror ()); \
- exit (EXIT_FAILURE); \
- } \
- } while (0)
-#define OPTIONAL_STUB(fn,ret,args) fn = dlsym (dl, #fn)
-#include "vddk-stubs.h"
-#undef STUB
-#undef OPTIONAL_STUB
-}
-
+/* Unload the plugin. */
static void
vddk_unload (void)
{
@@ -289,6 +242,54 @@ vddk_config (const char *key, const char *value)
return 0;
}
+/* Load the VDDK library. */
+static vo...
2019 Oct 11
3
[PATCH NOT WORKING nbdkit v2 0/2] vddk: Restructure plugin to allow greater parallelism.
This is my second attempt at this. The first version (also not
working) was here:
https://www.redhat.com/archives/libguestfs/2019-October/msg00062.html
In part 1/2 I introduce a new .ready_to_serve plugin method which is
called after forking and just before accepting any client connection.
The idea would be that plugins could start background threads here.
However this doesn't work well in
2020 Feb 17
5
[nbdkit PATCH v5 0/4] vddk: Drive library loading from libdir parameter.
Differences from v4:
Patch 1 is simplified: I realized that since we already use -rdynamic
for nbdkit (after all, we WANT our dlopen()d plugins to be able to
call our nbdkit_* exports), it is only a matter of adding dlopen to
the set of symbols that we export. With that done, there is no
separate shared library needed; our dlopen shim is now part of nbdkit
proper, and we don't have to tweak
2020 Feb 16
6
[nbdkit PATCH v4 0/4] vddk: Drive library loading from libdir parameter.
I'm a lot happier with this version: no mucking with dlmopen(). It
does add a bit more coupling between nbdkit proper and the vddk plugin
(namely, nbdkit now exports a new function that the vddk plugin relies
on), but patch 2 adds testsuite coverage of the new function so we
shouldn't regress.
Patch 1 and 2 are new, patch 3 is unchanged from when Rich posted it
in v2, and patch 4 is
2020 Jun 02
9
[PATCH nbdkit 0/5] vddk: Fix password parameter.
Probably needs a bit of cleanup, but seems like it is generally the
right direction.
One thing I've noticed is that the expect test randomly (but rarely)
hangs :-( I guess something is racey but I don't know what at the
moment.
Rich.
2020 Feb 25
6
[PATCH nbdkit 0/5] server: Add .get_ready callback.
I like this change. I think we were overloading the config_complete
method before to do two different things (complete configuration; do
any allocation/housekeeping necessary before we can start serving).
The only questions in my mind are whether we want this before 1.18,
and whether the name ("get_ready") is a good one.
Rich.