search for: nbdkit_reply

...equest handle value 3) nbdkit bundles the nbd request handle value, bool flush_on_update, and read size into an opaque ptr to struct 4) nbdkit calls my_plugin.pread passing in the usual args + the opaque ptr 5) my_plugin.pread makes an asynchronous read call with a handler set on completion to call nbdkit_reply_read(conn, opaque ptr, buf) or on error nbdkit_reply_error(conn, opaque_ptr, error) 6) my_plugin.pread returns back to nbdkit without error after it has started the async op but before it has completed 7) nbdkit doesn't send a response to the conn->sockout beause when the async op has compl...

...to struct > 4) nbdkit calls my_plugin.pread passing in the usual args + the opaque ptr We can't change the existing API, so this would have to be exposed through new plugin entry point(s). > 5) my_plugin.pread makes an asynchronous read call with a handler set on > completion to call nbdkit_reply_read(conn, opaque ptr, buf) or on error > nbdkit_reply_error(conn, opaque_ptr, error) > 6) my_plugin.pread returns back to nbdkit without error after it has > started the async op but before it has completed > 7) nbdkit doesn't send a response to the conn->sockout beause when th...

...t would function identically and send_reply is called after the plugin.pread + fua is finished. An alternative plugin struct "nbdkit_plugin_lowlevel" could define a different interface where an opaque ptr to the handle + connection + flags are passed in and the plugin is required to call nbdkit_reply (opaque *ptr, ...) to send the reply to the nbd client rather than nbdkit auto sending the reply after returning from the plugin function. Some pseudo code example changes for what I had in mind. struct operation { struct connection *conn; uint64_t handle; uint32_t cmd; uint32_t f...