similar to: [nbdkit PATCH] ocaml: Add support for dynamic .thread_model

Somewhat of a mishmash between .open (in that it takes a bool readonly parameter) and .config_complete (in that the C code returns an int, but the Ocaml code either throws an exception or completes with unit). I did not spot any existing testsuite coverage to modify for this, and am relying on the fact that it compiles cleanly. Signed-off-by: Eric Blake <eblake@redhat.com> ---

Fairly straightforward. I'd love for type export to be a bit more flexible to make description optional, but could not figure out how to decode that from the C side of things, so for now this just requires the caller to supply a description for all exports during .list_exports. Signed-off-by: Eric Blake <eblake at redhat.com> --- plugins/ocaml/NBDKit.mli | 9 ++++

Fairly straightforward. A user can supply { "name"; None } or { "name"; Some "description" } as desired. Signed-off-by: Eric Blake <eblake@redhat.com> --- plugins/ocaml/NBDKit.mli | 9 ++++ plugins/ocaml/NBDKit.ml | 17 ++++++++ plugins/ocaml/example.ml | 33 +++++++++----- plugins/ocaml/ocaml.c | 92 +++++++++++++++++++++++++++++++++++++++- 4 files

This was a bit harder than sh, but still a lot of copy-and-paste. Signed-off-by: Eric Blake <eblake@redhat.com> --- Note: I'm not sure how to actually test this beyond compilation. --- plugins/ocaml/ocaml.c | 51 ++++++++++++++++++++++++++++++++++++++++ plugins/ocaml/NBDKit.ml | 16 ++++++++++++- plugins/ocaml/NBDKit.mli | 5 ++++ 3 files changed, 71 insertions(+), 1 deletion(-)

Allow plugins to affect the handling of the new NBD_CMD_FLAG_FAST_ZERO flag, then update affected plugins. In particular, in-memory plugins are always fast; the full plugin is better served by omitting .zero and relying on .pwrite fallback; nbd takes advantage of libnbd extensions proposed in parallel to pass through support; and v2 language bindings expose the choice to their scripts. The

This picks up python and ocaml. Some of our languages are lacking a number of bindings (for example, lua and perl lack .extents, so I didn't have anything to copy from), and I felt less comfortable with golang and rust. But for python and ocaml, I was able to test a working implementation. Eric Blake (2): python: Implement .list_exports and friends ocaml: Implement .list_exports and

I like this change. I think we were overloading the config_complete method before to do two different things (complete configuration; do any allocation/housekeeping necessary before we can start serving). The only questions in my mind are whether we want this before 1.18, and whether the name ("get_ready") is a good one. Rich.

On Fri, Nov 22, 2019 at 9:54 PM Richard W.M. Jones <rjones@redhat.com> wrote: > > These are accessible from the plugin by: > > import nbdkit > > if flags & nbdkit.FLAG_MAY_TRIM: > &c. Nice way to expose the flags! > Many (all?) of these are not yet useful for plugins, some will never > be useful, but they only consume a tiny bit of memory and

On Fri, Nov 22, 2019 at 10:52 PM Richard W.M. Jones <rjones@redhat.com> wrote: > > On Fri, Nov 22, 2019 at 10:05:15PM +0200, Nir Soffer wrote: > > On Fri, Nov 22, 2019 at 9:54 PM Richard W.M. Jones <rjones@redhat.com> wrote: > > > > > > These are accessible from the plugin by: > > > > > > import nbdkit > > > > > > if

These are accessible from the plugin by: import nbdkit if flags & nbdkit.FLAG_MAY_TRIM: &c. Many (all?) of these are not yet useful for plugins, some will never be useful, but they only consume a tiny bit of memory and it's nice to have the complete set available for future use. --- plugins/python/python.c | 27 +++++++++++++++++++++++++++ 1 file changed, 27 insertions(+)

On Fri, Nov 22, 2019 at 10:05:15PM +0200, Nir Soffer wrote: > On Fri, Nov 22, 2019 at 9:54 PM Richard W.M. Jones <rjones@redhat.com> wrote: > > > > These are accessible from the plugin by: > > > > import nbdkit > > > > if flags & nbdkit.FLAG_MAY_TRIM: > > &c. > > Nice way to expose the flags! > > > Many (all?) of

If you have a plugin which either creates background threads itself or uses a library that creates background threads, it turns out you cannot create these in .get_ready (or earlier). The reason is that nbdkit forks when either daemonizing itself or using the --run option, and fork cancels all the background threads in the child process (the daemonized or captive nbdkit). The only good solution

First thing to say is that I need to do a *lot* more testing on this, so this is just an early peek. In particular, although it passed ‘make check && make check-valgrind’ I have *not* tested it against a multi-conn-aware client such as the Linux kernel >= 4.9. This implements NBD_FLAG_CAN_MULTI_CONN, described in the protocol doc as: "NBD_FLAG_CAN_MULTI_CONN: Indicates that

For existing commits, this is almost identical to v1, except that I updated some commit messages and reordered the commits in a somewhat more logical sequence. The main changes are the extra commits: [06/11] plugins: Return NBD_FLAG_CAN_MULTI_CONN from some readonly plugins. - Readonly plugins that can set the flag unconditionally. [09/11] partitioning: Return NBD_FLAG_CAN_MULTI_CONN. [10/11]

Rich pointed out that making thread_model dynamic even for plugins makes some sense, so here is the code for doing it for 'sh'. I'm less confident on how to do it for OCaml and Rust (not to mention that those allow the plugin to already compile in their model, rather than the language binding glue forcing a model). The other languages (lua, perl, python, ruby) still need to be

And fill out most of the missing bits of the API. Rich.

v1: https://www.redhat.com/archives/libguestfs/2019-November/msg00153.html v2: - Fix implementation of can_cache. - Add implementation of can_fua. - Add a very thorough test suite which tests every command + flag combination.

Similar to what I just did for OCaml (this IS an API break, requiring recompilation of any existing Rust plugin), and done because I want to add fast_zero support to both languages as part of my upcoming fast zero series. Figuring out how to get extents working was hard enough that I punted that, still. Eric Blake (2): rust: Implement can_cache rust: Add support for dynamic .thread_model

On Fri, Aug 16, 2019 at 12:08:11PM -0500, Eric Blake wrote: > We do not promise API stability for non-C languages; this is an API > break as follows: instead of calling plugin_init with a static model, > you can now populate .thread_model in the Plugin struct, with a > default to Parallel. As in C, the model is still chosen at .load time > (at most, making it a function allows you

Since v1: - rework .can_cache to be tri-state, with default of no advertisement (ripple effect through other patches) - add a lot more patches in order to round out filter support And in the meantime, Rich pushed NBD_CMD_CACHE support into libnbd, so in theory we now have a way to test cache commands through the entire stack. Eric Blake (24): server: Internal hooks for implementing