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

[Richard W.M. Jones]

On Fri, Mar 27, 2020 at 07:58:30AM -0500, Eric Blake wrote:
> 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).

Oh I see.  I'm not sure if there's a way to prevent someone linking a
main program to -lnbdkit and still let nbdkit itself link.  Maybe as
you say we need documentation.

Rich.

> >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

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
virt-top is 'top' for virtual machines.  Tiny program with many
powerful monitoring features, net stats, disk stats, logging, etc.
http://people.redhat.com/~rjones/virt-top