search for: nbdkit_extents_array

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

...g 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 nbdk...

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