[Libguestfs] [PATCH nbdkit] server: Implement extents/can_extents calls for plugins and filters.

[Eric Blake]

On 3/12/19 6:20 AM, Richard W.M. Jones wrote:
> This tentative commit implements extents/can_extents, roughly as
> discussed in the previous thread here:
> 
> https://www.redhat.com/archives/libguestfs/2019-March/msg00017.html
> 
> I can't say that I'm a big fan of having the plugin allocate an
> extents array.  There are no other plugin callbacks currently where we
> require the plugin to allocate complex data structures (or indeed do
> any allocation at all).  The interface is complex and error prone for
> plugin writers.  However I can't at the moment think of a better way
> to do it.

Can we at least provide a utility function that the plugin can call to
obtain an array containing N extents, where nbdkit does the
malloc()/free() rather than mixing malloc() in plugin and free() in
nbdkit?  Among other things, doing this would let us switch to a
different allocation engine (pool-based, maybe?) without a super-close
coupling where plugins and nbdkit have to share the same allocator.

nbdkit        plugin
receive client BLOCK_STATUS call
call plugin.extents
              call nbdkit_extents_array(N)
allocate an array of N extents
              populate the array and return
process the array


The only other thing I can think of is that nbdkit could have a function
that the plugin must call one or more times per extent, before
returning, and where nbdkit collects the extents itself based on the
sequence of calls rather than making the plugin itself manage an array.

nbdkit        plugin
receive client BLOCK_STATUS call
initialize array
call plugin.extents
              call nbdkit_extent_add()
add extent to array
              call nbdkit_extent_add()
add extent to array
              ...
              return
process the array

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

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: OpenPGP digital signature
URL: <http://listman.redhat.com/archives/libguestfs/attachments/20190312/ef64a658/attachment.sig>