On 3/25/20 7:16 AM, Richard W.M. Jones wrote:
 I think I understand now that libnbdkit.so won't break the ABI
for
 existing plugins.  Does it require that plugins for newer nbdkit use
 -lnbdkit (which would be a source API break) or would it still be
 possible to compile without this?  I guess as long as plugins do not
 start using -no-undefined then it would still work, so it wouldn't be
 a source API break. 
Yes, that's what I'm thinking - it's an API break if you have to add in 
-lnbdkit; but you only have to add that if you want to use 
-no-undefined. Plugins compiled without -lnbdkit (either because they 
predate the library, or because they specifically did not care about 
-no-undefined) should still be viable.
 
 I had a look into how we might implement libnbdkit.so.  Some functions
 are obviously self-contained (eg. nbdkit_parse_*, nbdkit_realpath,
 nbdkit_debug, nbdkit_error, nbdkit_*extents).
 
 Unfortunately some functions depend themselves on internals
 of the server:
 
   * nbdkit_nanosleep, nbdkit_export_name, nbdkit_peer_name call
     threadlocal_get_conn
   * nbdkit_set_error calls threadlocal_set_error
   * nbdkit_shutdown must set the quit global (or call a server function) 
Yeah, there's some awkward dependencies to figure out. It's obvious the 
library has to export public nbdkit_* interfaces for the sake of 
plugins, but can it also export one additional symbol _nbdkit_init() for 
internal use?  Then we can have the nbdkit binary pass whatever 
additional hooks are needed for proper isolation of the public interface 
(a callback pointer to get at threadlocal_get_conn, 
threadlocal_set_error, the address of the quit global, ...), and leave 
the symbol undocumented (plus the fact that the leading _ will 
discourage plugins from trying to abuse it).
 
 I guess we can deal with the first ones by moving threadlocal.c into
 the same library, although it's a bit awkward.  The quit flag is still
 more awkward because you have to move a lot of quit pipe handling code
 into the library which has knock-on effects all over. 
The other extreme is to have the entire nbdkit engine in libnbdkit.so, 
plus the addition of a single internal-only callback _nbdkit_main(), 
then the nbdkit binary becomes a bare-bones:
int main (int argc, char *argv[]) {
   return _nbdkit_main (argc, argv);
}
at which point you don't have to decide which functionality lives where. 
  After all, you already have a linker script that limits what the main 
binary exports; which really becomes what libnbdkit.so has to export. 
If we are worried about plugins trying to abuse that additional entry 
point, you can have _nbdkit_main set a flag on first execution so that 
subsequent attempts to call it fail immediately; but I'm not too worried 
about it.
-- 
Eric Blake, Principal Software Engineer
Red Hat, Inc.           +1-919-301-3226
Virtualization:  
qemu.org | 
libvirt.org