Displaying 3 results from an estimated 3 matches for "my_filter_prepar".
Did you mean:
my_filter_prepare
2020 Jul 09
1
Re: [nbdkit PATCH] filters: Improve docs on .prepare prerequisites
...d in most other cases thanks to
>> +client negotiation, the timing of C<.prepare> comes before client
>> +negotiation has completed.
>
> I think this isn't sufficient. I think a filter which does:
>
> int64_t my_filter_get_size () { return size; }
> int my_filter_prepare (int readonly) { return 0; }
>
> will fail as h->exportsize is only updated by a call to
> next_ops->get_size. This is basically what the tar filter was doing
> on the second connection (before I fixed it).
True. But I'm not sure how best to word it. Ultimately, a filter...
2020 Jul 09
2
[nbdkit PATCH] filters: Improve docs on .prepare prerequisites
Since .prepare is called before client negotiation has completed,
filters have an additional burden to ensure prerequisite functions are
called in order to avoid triggering assertions in backend.c.
See also: https://bugzilla.redhat.com/show_bug.cgi?id=1855330,
https://www.redhat.com/archives/libguestfs/2020-July/msg00041.html
Signed-off-by: Eric Blake <eblake@redhat.com>
---
2020 Jul 09
0
Re: [nbdkit PATCH] filters: Improve docs on .prepare prerequisites
...requisites are automatically handled in most other cases thanks to
> +client negotiation, the timing of C<.prepare> comes before client
> +negotiation has completed.
I think this isn't sufficient. I think a filter which does:
int64_t my_filter_get_size () { return size; }
int my_filter_prepare (int readonly) { return 0; }
will fail as h->exportsize is only updated by a call to
next_ops->get_size. This is basically what the tar filter was doing
on the second connection (before I fixed it).
Rich.
> There is no C<next_ops-E<gt>prepare> or C<next_ops-E<gt>...