similar to: [PATCH nbdkit] vddk: Suppress errors in can_extents test (RHBZ#1709211).

We were previously dlopen-ing it in the load() method. This is very early and in particular means that the only possible way to configure where we find the library is through environment variables and not through config parameters. Also it's not necessary as we don't call any functions from the library (such as VixDiskLib_InitEx) until config_complete. This change is neutral refactoring

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

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

Pure refactoring. Just decouples the complicated reexec code from the rest. --- plugins/vddk/Makefile.am | 2 + plugins/vddk/vddk.h | 42 +++++++++ plugins/vddk/reexec.c | 196 +++++++++++++++++++++++++++++++++++++++ plugins/vddk/vddk.c | 151 ++---------------------------- 4 files changed, 246 insertions(+), 145 deletions(-) diff --git a/plugins/vddk/Makefile.am

Make it behave more or less like a real VDDK. Of course it ignores all parameters passed and emulates a blank disk, but that is sufficient to do some more realistic testing. --- plugins/vddk/vddk-stubs.h | 8 --- tests/dummy-vddk.c | 115 ++++++++++++++++++++++++++++++++++---- 2 files changed, 103 insertions(+), 20 deletions(-) diff --git a/plugins/vddk/vddk-stubs.h

This uses a new API VixDiskLib_QueryAllocatedBlocks provided in VDDK >= 6.7. Thanks: Martin Kletzander. --- plugins/vddk/vddk-structs.h | 15 +++- plugins/vddk/vddk.c | 138 ++++++++++++++++++++++++++++++++++++ 2 files changed, 152 insertions(+), 1 deletion(-) diff --git a/plugins/vddk/vddk-structs.h b/plugins/vddk/vddk-structs.h index dbed94a..df88322 100644 ---

In the next patch, we want to get rid of the requirement for the user to supply LD_LIBRARY_PATH pointing to vddk libs, if we can derive it ourselves from libdir. However, VDDK itself requires LD_LIBRARY_PATH to be set (because it tries to load libraries that in turn depend on a bare library name, which no manner of dlopen() hacking can work around, and implementing la_objsearch() is no better for

Greetinigs, I am extending llc to include runtime checks for calls (in X86). So a call 'call target' is altered to look like this: [some check] jne error_function call target I've done this by implementing a MachineFunctionPass that is instantiated and added to the PassManager in X86TargetMachine::addPreRegAlloc. In order to create the jne-instruction I need some BasicBlock

From: "Richard W.M. Jones" <rjones@redhat.com> Do not use LD_LIBRARY_PATH to locate the VDDK library. Setting this always causes problems because VDDK comes bundled with broken replacements for system libraries, such as libcrypto.so and libstdc++.so. Two problems this causes which we have seen in the real world: (1) User does ‘export LD_LIBRARY_PATH=vmware-vix-disklib-distrib’

On Aug 2, 2009, at 7:09 AM, Artjom Kochtchi wrote: > > Greetinigs, > > I am extending llc to include runtime checks for calls (in X86). So > a call > 'call target' is altered to look like this: > > [some check] > jne error_function > call target > > I've done this by implementing a MachineFunctionPass that is > instantiated > and added

That version depends on libexpat.so but does not ship it, and it appears that VMware no longer supports it. Since VDDK 5.5.5 (the next oldest version) dropped support for 32-bit platforms, we can slightly simplify our code by documenting our minimum supported version. Signed-off-by: Eric Blake <eblake@redhat.com> --- v2: scrub for more places to clean up, based on Rich's review of v1

From: "Richard W.M. Jones" <rjones@redhat.com> Do not use LD_LIBRARY_PATH to locate the VDDK library. Setting this always causes problems because VDDK comes bundled with broken replacements for system libraries, such as libcrypto.so and libstdc++.so. Two problems this causes which we have seen in the real world: (1) User does ‘export LD_LIBRARY_PATH=vmware-vix-disklib-distrib’

On Sat, Mar 23, 2019 at 02:29:54PM -0500, Eric Blake wrote: > On 3/20/19 5:11 PM, Richard W.M. Jones wrote: ... > > + for (i = 0; i < block_list->numBlocks; ++i) { > > + uint64_t offset, length; > > + > > + offset = block_list->blocks[i].offset * VIXDISKLIB_SECTOR_SIZE; > > + length = block_list->blocks[i].length *

On 3/20/19 5:11 PM, Richard W.M. Jones wrote: > This uses a new API VixDiskLib_QueryAllocatedBlocks provided in > VDDK >= 6.7. > > Thanks: Martin Kletzander. > --- > plugins/vddk/vddk-structs.h | 15 +++- > plugins/vddk/vddk.c | 138 ++++++++++++++++++++++++++++++++++++ > 2 files changed, 152 insertions(+), 1 deletion(-) > > +static int >

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

On Mon, Mar 25, 2019 at 05:34:25PM +0000, Richard W.M. Jones wrote: > On Sat, Mar 23, 2019 at 02:29:54PM -0500, Eric Blake wrote: > > On 3/20/19 5:11 PM, Richard W.M. Jones wrote: > ... > > > + for (i = 0; i < block_list->numBlocks; ++i) { > > > + uint64_t offset, length; > > > + > > > + offset = block_list->blocks[i].offset *

On 3/12/19 6:20 AM, Richard W.M. Jones wrote: > This tentative commit implements extents/can_extents, roughly as > discussed in the previous thread here: > > https://www.redhat.com/archives/libguestfs/2019-March/msg00017.html > > I can't say that I'm a big fan of having the plugin allocate an > extents array. There are no other plugin callbacks currently where we

On Mon, Mar 25, 2019 at 05:01:39PM +0000, Richard W.M. Jones wrote: > > > +=head2 C<.can_extents> [...] > There is definitely a case for removing can_extents completely, and > relying on the fallback. Would this affect language bindings? I > think no because in the language bindings we can also emulate the > .extents callback. > > Associated with this change

On Tue, Mar 12, 2019 at 01:23:37PM +0100, Martin Kletzander wrote: > >+=head2 C<.extents> > >+ > >+ int zero (void *handle, uint32_t count, uint64_t offset, uint32_t flags, > > s/zero/extents/ Oops. > >+ if (f->filter.extents) > >+ return f->filter.extents (&next_ops, &nxdata, handle, > >+ count,

On 8/10/20 5:50 AM, Richard W.M. Jones wrote: > --- > plugins/python/nbdkit-python-plugin.pod | 19 ++++++- > plugins/python/python.c | 75 +++++++++++++++++++++++++ > tests/test-python-plugin.py | 8 ++- > tests/test_python.py | 73 +++++++++++++++++++++++- > 4 files changed, 169 insertions(+), 6 deletions(-) > > diff