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