On 2/18/20 4:48 AM, Richard W.M. Jones wrote:
Since VDDK only runs on Linux, we can assume the presence of
/proc/self/{exe,cmdline}, and parse off everything we need (provided
nbdkit didn't muck with argv[], which we just fixed) to recursively
exec with a munged environment that still has enough breadcrumbs to
undo the munging.
This patch does not quite set LD_LIBRARY_PATH correctly in all cases
(since vddk expects libdir= to point to vmware-vix-disklib-distrib/,
but LD_LIBRARY_PATH to vmware-vix-disklib-distrib/lib64), but that
will be cleaned up in the next patch; in the meantime, the re-exec in
this patch fires but has no ill effects.
@@ -72,7 +73,8 @@ int vddk_debug_extents;
#define VDDK_MINOR 1
static void *dl = NULL; /* dlopen handle */
-static int init_called = 0; /* was InitEx called */
+static bool init_called = false; /* was InitEx called */
+static char *reexeced = false; /* did libdir require reexec */
I guess this works, but is "NULL" better than "false"?
Rebasing snafu - I originally started with bool reexeced, then realized
that I need to be smarter about what prefix to strip off of
LD_LIBRARY_PATH (as pointed out above, we generally want "$libdir/lib64"
rather than bare "$libdir" as the LD_LIBRARY_PATH entry, since
VixDiskLib_InitEx() asks for libdir). Next I added a second config
parameter (one bool, one the string to strip), got it working, then
realized I could merge it back into one variable (the string to strip
behaves as the bool), but forgot to change the initializer to match.
As it is, C guarantees that all static variables are 0-initialized, so =
NULL, = 0, and = false are all redundant in this section of the file.
+ /* If load_library caused a re-execution with an expanded
+ * LD_LIBRARY_PATH, restore it back to its original contents.
+ * dlopen uses the value of LD_LIBRARY_PATH cached at program
+ * startup; our change is for the sake of child processes (such as
+ * --run) to see the same environment as the original nbdkit saw
+ * before re-exec.
+ */
Could we pass the original LD_LIBRARY_PATH on the command line too?
Yes, that's an option. Linux in general allows long command lines, so
we're unlikely to run into command-line length limits by doing so, and
having the full original LD_LIBRARY_PATH makes it easier to replace the
extended one.
--
Eric Blake, Principal Software Engineer
Red Hat, Inc. +1-919-301-3226
Virtualization: qemu.org | libvirt.org
_______________________________________________
Libguestfs mailing list
[email protected]
https://www.redhat.com/mailman/listinfo/libguestfs
