search for: flag_one

...> + nbdkit_extents_callback fn, void *opaque, > + uint32_t flags, > + uint64_t range_offset, uint64_t range_length) > +{ > + const bool flag_range = flags & NBDKIT_EXTENTS_FOREACH_FLAG_RANGE; > + const bool flag_one = flags & NBDKIT_EXTENTS_FOREACH_FLAG_ONE; > + uint64_t offset, next; > + size_t i; > + > + if (flag_range) { > + if (range_offset + range_length < range_offset) { > + nbdkit_error ("nbdkit_extents_foreach: invalid range: " > + &qu...

I want to post this but mainly for discussion and early review. It's not safe for these patches to all go upstream yet (because not all filters have been checked/adjusted), but if any patches were to go upstream then probably 1 & 2 only are safe. File, VDDK, memory and data plugins all work, although I have only done minimal testing on them. The current tests, such as they are, all

...ccess or C<-1> on failure. +On internal failures it calls C<nbdkit_error> or C<nbdkit_set_error>. +If C<fn> fails it is expected that C<fn> calls those functions as +necessary. + +The C<flags> parameter can contain: + +=over 4 + +=item C<NBDKIT_EXTENTS_FOREACH_FLAG_ONE> + +Only call C<fn> for the first extent, and then return. (This is used +to implement C<NBD_CMD_FLAG_REQ_ONE> in the NBD protocol.) + +=item C<NBDKIT_EXTENTS_FOREACH_FLAG_RANGE> + +If this flag is included then the C<range_offset> and C<range_length> +parameters a...

...e of these a while back and it's very complex. I've cut some other comments about the structure because I want to see if implementing this using an array which always contains extents covering the full range is simpler. [...] > The NBD protocol allows for short replies (whether or not FLAG_ONE was > requested) - should we have a fifth type that the plugin can call > _add(END) as a way of specifically marking that they did not provide > extent information beyond that point, and therefore nbdkit must do a > short reply (instead of treating the rest of the range as data)? (For...