search for: nbd_aio_foo_notify

...mplete. It's also desirable when writing a server >> validation program (such as for checking structured reads for >> compliance) to be able to clean up the associated opaque data and have >> a final chance to change the overall command status. >> >> Introduce new nbd_aio_FOO_notify functions for each command. Rewire >> the existing nbd_aio_FOO to forward to the new command. (Perhaps the >> generator could reduce some of the boilerplate duplication, if a later >> patch wants to refactor this). > > I'm writing some code now using these new nbd_aio_...

...gt; commands are complete. It's also desirable when writing a server > validation program (such as for checking structured reads for > compliance) to be able to clean up the associated opaque data and have > a final chance to change the overall command status. > > Introduce new nbd_aio_FOO_notify functions for each command. Rewire > the existing nbd_aio_FOO to forward to the new command. (Perhaps the > generator could reduce some of the boilerplate duplication, if a later > patch wants to refactor this). I'm writing some code now using these new nbd_aio_<CMD>_notify fun...

Obvious change given the previous patch, so ACK. I do wonder if we should make the notify parameter mandatory (and therefore avoid the duplicate functions). Another trick you might do if feeling really keen is to programmatically generate the notify variants of commands, something like this: let make_notify_variant_of_call ({ args; longdesc } as call) = let args = List.rev args in let

...hat structure to learn which commands are complete. It's also desirable when writing a server validation program (such as for checking structured reads for compliance) to be able to clean up the associated opaque data and have a final chance to change the overall command status. Introduce new nbd_aio_FOO_notify functions for each command. Rewire the existing nbd_aio_FOO to forward to the new command. (Perhaps the generator could reduce some of the boilerplate duplication, if a later patch wants to refactor this). --- docs/libnbd.pod | 22 +++- generator/generator | 278 +++++++++++++++++++++++++++++...

...tus also call the > callback for all chunks from the server, rather than stopping the use of > further callbacks once the first callback fails, if only for consistency > between the two? So now I'm leaning towards making that change, particularly since I'm also working on adding a nbd_aio_FOO_notify() for each command that takes a callback that also takes an error pointer. > >>> One last thing is that I could not find any definition for the flags >>> of "base:allocation" metadata (NBD_STATE_HOLE and NBD_STATE_ZERO). >>> It might just be things that are...

On 6/25/19 8:14 AM, Richard W.M. Jones wrote: > On Tue, Jun 25, 2019 at 02:58:34PM +0200, Martin Kletzander wrote: >> Here are few things I found out when using libnbd that might be perfectly fine >> or maybe just an oversight, but I wanted to point them out. It's nothing major. >> >> When running a program with `nbdkit -U - --run ...`, the $nbd parameter gets

...he code any faster or easier to maintain, but at least the added example shows one good use case for the new API. Eric Blake (6): api: Add nbd_aio_in_flight generator: Allow DEAD state actions to run generator: Allow Int64 in callbacks states: Prepare for aio notify callback api: Add new nbd_aio_FOO_notify functions examples: New example for strict read validations .gitignore | 1 + docs/libnbd.pod | 22 +- examples/Makefile.am | 14 + examples/batched-read-write.c | 17 +- examples/stri...