On 12/14/18 4:16 PM, Richard W.M. Jones wrote:
This allows us to add the following callbacks:
- can_zero returns boolean - can_fua should print "none", "emulate" or "native"
Furthermore the following callbacks are modified in a backwards compatible manner:
- pwrite adding flags parameter - trim adding flags parameter
This change is not backwards compatible:
- zero may_trim parameter replaced by flags parameter --- plugins/sh/nbdkit-sh-plugin.pod | 41 +++++++++++--- plugins/sh/sh.c | 99 +++++++++++++++++++++++++++------ 2 files changed, 115 insertions(+), 25 deletions(-)
+=item C<can_fua> + + /path/to/script can_fua <handle> + +This controls Forced Unit Access (FUA) behaviour of the core server. +Unlike the other C<can_*> callbacks, this one is I<not> a boolean. It +must print either "none", "emulate" or "native". The meaning of these
Worth adding 'to stdout'?
+is described in L<nbdkit-plugin(3)>. + =item C<pread>
/path/to/script pread <handle> <count> <offset> @@ -227,10 +240,13 @@ This method is required.
=item C<pwrite>
- /path/to/script pwrite <handle> <count> <offset> + /path/to/script pwrite <handle> <count> <offset> <flags>
The script should read the binary data to be written from stdin.
+The C<flags> parameter can be an empty string or C<"fua">. In future
s/In future/In the future,/
+a comma-separated list of flags may be present.
Is the empty string "" always provided as an argument, or will the argument be omitted in that case?
+ Unlike in other languages, if you provide a C<pwrite> method you B<must> also provide a C<can_write> method which exits with code C<0> (true). @@ -245,16 +261,23 @@ B<must> also provide a C<can_flush> method which exits with code C<0>
=item C<trim>
- /path/to/script trim <handle> <count> <offset> + /path/to/script trim <handle> <count> <offset> <flags> + +The C<flags> parameter can be an empty string or C<"fua">. In future
Copy-and-paste "In future"
+a comma-separated list of flags may be present.
Unlike in other languages, if you provide a C<trim> method you B<must> also provide a C<can_trim> method which exits with code C<0> (true).
=item C<zero>
- /path/to/script zero <handle> <count> <offset> <may_trim> + /path/to/script zero <handle> <count> <offset> <flags>
-C<may_trim> will be either C<true> or C<false>. +The C<flags> parameter can be an empty string or C<"fua">. In future +a comma-separated list of flags may be present.
This one is wrong, since you have both fua and may_trim now.
+ + case RET_FALSE: + free (s); + nbdkit_error ("%s: %s method returned unexpected code (3/false)", + script, "can_fua");
Could we be nice and treat this as "none"?
@@ -538,12 +602,13 @@ sh_trim (void *handle, uint32_t count, uint64_t offset) }
static int -sh_zero (void *handle, uint32_t count, uint64_t offset, int may_trim) +sh_zero (void *handle, uint32_t count, uint64_t offset, uint32_t flags) { char *h = handle; char cbuf[32], obuf[32]; - const char *args[] = { script, "zero", h, cbuf, obuf, - may_trim ? "true" : "false", NULL }; + /* In future, comma-separated list of flags. */
While I commented about 'in future' being too terse in the .pod, I don't mind it being compressed in the .c file. On the other hand, the comment here is wrong, as sh_zero needs to handle both fua and may_trim flags.
+ const char *sflags = flags & NBDKIT_FLAG_FUA ? "fua" : "";
and thus this computation for sflags is incomplete. Otherwise, looking good. -- Eric Blake, Principal Software Engineer Red Hat, Inc. +1-919-301-3266 Virtualization: qemu.org | libvirt.org