[Libguestfs] nbdkit / mingw support
Eric Blake
eblake at redhat.com
Wed Mar 25 13:25:32 UTC 2020
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
More information about the Libguestfs
mailing list