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

[Martin Kletzander]

On Tue, Mar 12, 2019 at 12:41:44PM +0000, Richard W.M. Jones wrote:
>On Tue, Mar 12, 2019 at 01:23:37PM +0100, Martin Kletzander wrote:
>> >+=head2 C<.extents>
>> >+
>> >+ int zero (void *handle, uint32_t count, uint64_t offset, uint32_t flags,
>>
>> s/zero/extents/
>
>Oops.
>
>> >+  if (f->filter.extents)
>> >+    return f->filter.extents (&next_ops, &nxdata, handle,
>> >+                              count, offset, flags,
>> >+                              nr_extents, extents, err);
>> >+  else
>> >+    return f->backend.next->extents (f->backend.next, conn,
>> >+                                     count, offset, flags,
>> >+                                     nr_extents, extents, err);
>>
>> Do I understand it correctly that if a filter does not support
>> extents, then its function will only be applied on the allocated
>> blocks?  It makes sense, but I feel like it would be nice to have
>> that mentioned somewhere.
>
>No.  The code snippet above allows filters to intercept the extents
>call and modify it (either on the way in, or the way out, or most
>likely in this case both).  The conditional ‘if (f->filter.extents)’
>is checking if the filter has an extents callback, which is the
>callback that the filter has to provide to do this interception.
>
>I think most filters will need to be adjusted by adding an extents
>callback.  Certainly any filter which deals with offsets (most
>obviously nbdkit-offset-filter, nbdkit-partition-filter) will need to
>implement the .extents call and both adjust the offset parameter that
>is passed down, and examine the list of extents being returned through
>the filter and adjust the offsets inside that list.
>
>This is the broad reason why we don't offer a stable API for filters
>(unlike plugins).  Nor do we advise that it's a good idea to
>distribute filters separately from nbdkit.  If an old filter was used
>with a plugin which was using the extents API then the filter would
>basically corrupt data.
>

Oh, ok, makes sense.

>> Other than that it looks OK to me, I'll try to cook up a test filter
>> to test this, but mainly as a fun exercise for myself.
>
>So note at the moment this patch doesn't really do anything.  nbdkit
>server still doesn't support block status, so neither of the functions
>will ever be called.  This patch was just for discussion about what
>the plugin API might look like.
>

I'll have it prepared when the time comes then.

>Rich.
>
>-- 
>Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
>Read my programming and virtualization blog: http://rwmj.wordpress.com
>virt-df lists disk usage of guests without needing to install any
>software inside the virtual machine.  Supports Linux and Windows.
>http://people.redhat.com/~rjones/virt-df/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/libguestfs/attachments/20190312/605290eb/attachment.sig>