similar to: [nbdkit PATCH v6] vddk: Add re-exec with altered environment

Displaying 20 results from an estimated 8000 matches similar to: "[nbdkit PATCH v6] vddk: Add re-exec with altered environment"

2020 Feb 18
4
[nbdkit PATCH v7 0/2] vddk: Drive library loading from libdir parameter.
In v7: everything should work now! The re-exec code is slightly simplified, with Rich's suggestion to pass the original LD_LIBRARY_PATH rather than just the prefix being added, and I've now finished wiring up the initial dlopen() check into code that correctly computes the right prefix dir to add to LD_LIBRARY_PATH. Eric Blake (1): vddk: Add re-exec with altered environment Richard
2020 Jun 02
0
[PATCH nbdkit 2/5] vddk: Move reexec code to a new file.
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
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 18
0
Re: [nbdkit PATCH v6] vddk: Add re-exec with altered environment
On Mon, Feb 17, 2020 at 09:34:12PM -0600, Eric Blake wrote: > 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
2020 Feb 18
0
[nbdkit PATCH v7 2/2] vddk: Drive library loading from libdir parameter.
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’
2020 May 07
1
[PATCH nbdkit] vddk: Suppress errors in can_extents test (RHBZ#1709211).
In can_extents we test whether the VDDK function VixDiskLib_QueryAllocatedBlocks works before declaring that extents are supported. This VDDK function can fail in several ways but most notable if the server doesn't support querying extents. In this case VDDK raises an error message through the error_function callback, which we turn into a call to nbdkit_error. In most cases this will cause
2020 Feb 13
1
[nbdkit PATCH v3] vddk: Drive library loading from libdir parameter.
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’
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 13
2
[PATCH nbdkit 1/2] vddk: Delay loading VDDK until config_complete.
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
2020 Apr 03
1
[nbdkit PATCH v2] vddk: Drop support for VDDK 5.1.1
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
2020 Feb 13
1
Re: [PATCH nbdkit 2/2] vddk: Drive library loading from libdir parameter.
On 2/13/20 8:01 AM, Richard W.M. Jones wrote: > 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
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
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 17
0
[nbdkit PATCH v5 4/4] vddk: Drive library loading from libdir parameter.
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’
2020 Jun 02
0
[PATCH nbdkit 3/5] vddk: Miscellaneous improvements to reexec code.
Use an extensible buffer (a vector<char>) when reading /proc/self/cmdline. Tidy up some error messages. --- plugins/vddk/reexec.c | 57 ++++++++++++++++++++++++++----------------- 1 file changed, 35 insertions(+), 22 deletions(-) diff --git a/plugins/vddk/reexec.c b/plugins/vddk/reexec.c index 5a5e9844..9641ee8c 100644 --- a/plugins/vddk/reexec.c +++ b/plugins/vddk/reexec.c @@ -48,6
2020 Feb 17
2
Re: [nbdkit PATCH v5 4/4] vddk: Drive library loading from libdir parameter.
Unfortunately this series doesn't work with the real VDDK library :-( I see: nbdkit: debug: vddk: config_complete nbdkit: debug: dlopen shim prefix set to /home/rjones/tmp/vddk-6.7.3/vmware-vix-disklib-distrib/lib64 Then a little bit later during VDDK initialization it fails with: nbdkit: debug: VixDiskLib: Could not load default plugins from
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
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 13
0
[PATCH nbdkit 2/2] vddk: Drive library loading from libdir parameter.
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’ and that breaks lots of ordinary utilities on their system. (2)
2019 Apr 12
2
Re: nbdkit, VDDK, extents, readahead, etc
On Fri, Apr 12, 2019 at 03:52:58PM +0200, Martin Kletzander wrote: > On Thu, Apr 11, 2019 at 06:55:55PM +0100, Richard W.M. Jones wrote: > >This seems to be a bug in VDDK, possibly connected with the fact that > >we fork after initializing VDDK but before doing the > >VixDiskLib_ConnectEx. I suspect it's something to do with the PID > >changing. > > >