On 3/25/20 8:01 AM, Richard W.M. Jones wrote:

Unfortunately some functions depend themselves on internals
of the server:

  * nbdkit_nanosleep, nbdkit_export_name, nbdkit_peer_name call
  * 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).

Yes this is a good point.

Also I suppose this interface between nbdkit <-> libnbdkit.so is
*not* ABI so we can change this at will?  It would mean that
nbdkit & libnbdkit.so must always be shipped together, but that
doesn't seem to be a problem.

Yes, I can live with that. Similar to how we declare that while plugins are API/ABI-compatible across versions, filters are not, and to run a filter, it must come from the same sources as the nbdkit binary. So I don't see it as a problem to change our undocumented _nbdkit_internal() entry point at will. Of course, it is still wise to make our internal interface robust enough to make it easy to detect if a user has ever accidentally mismatched versions, such as declaring that the first parameter is a version number regardless of how other parameters change over time.

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

Libguestfs mailing list

Reply via email to