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