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