[Libguestfs] [PATCH nbdkit 5/9 patch split 2/5] lib: Move code for parsing, passwords and paths into libnbdkit.so.

Eric Blake eblake at redhat.com
Fri Mar 27 12:58:30 UTC 2020


On 3/26/20 5:42 PM, Richard W.M. Jones wrote:
> On Thu, Mar 26, 2020 at 04:35:29PM -0500, Eric Blake wrote:
>> Should the test-public binary still be compiled from direct files
>> under lib/, or should it be linked against libnbdkit.so?
> 
> I will fix this in my copy.
> 
>> I'm wondering if we want to add some sort of
>> 'assert(is_initialized)' to all of our public entry functions to
>> ensure that no one is actually trying to use libnbdkit.so without
>> having first gone through nbdkit_private_init;[...]
> 
> So firstly I believe this can only be a problem if the server itself
> uses __attribute__((constructor)), since plugins and filters are
> always dlopened long after main() in the server has run.  Is that
> correct?

Right. I'm not worried about plugins ever running at a point where they 
would see libnbdkit.so uninitialized, but more about anyone trying to 
compile a standalone binary with its own main() but linked against 
libnbdkit.so.  Maybe it's just a matter of documentation: we state that 
the library exists solely for linking purposes of a plugin, and not for 
standalone binaries (since the only standalone binary that knows how to 
use it is nbdkit itself).

> 
> The only ((constructor)) currently used is in the OCaml plugin.
> 
> If the server does use a constructor and calls (eg) nbdkit_debug it
> would indeed crash.  However constructors would likely crash in the
> pre-change nbdkit because nothing in the server is initialized
> properly until main() is running.
> 
> Is it worth checking for this still, given it would have an overhead?

You've convinced me - there's no need to add checks, because either they 
are pointless overhead when the library is used correctly, or the user 
is abusing the library and deserves to crash because they are using it 
incorrectly.

-- 
Eric Blake, Principal Software Engineer
Red Hat, Inc.           +1-919-301-3226
Virtualization:  qemu.org | libvirt.org




More information about the Libguestfs mailing list