[Libguestfs] nbdkit / mingw support

[Eric Blake]

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