Re: [Libguestfs] [PATCH nbdkit 5/9 patch split 2/5] lib: Move code for parsing, passwords and paths into libnbdkit.so.
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