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