search for: list_export

...s(-) diff --git a/docs/nbdkit-plugin.pod b/docs/nbdkit-plugin.pod index f8e9962a..7ce89e9e 100644 --- a/docs/nbdkit-plugin.pod +++ b/docs/nbdkit-plugin.pod @@ -152,6 +152,9 @@ the plugin: │ preconnect │ │ └──────┬─────┘ │ ┌──────┴─────┐ │ + │list_exports│ │ + └──────┬─────┘ │ + ┌──────┴─────┐ │ │ open │ │ └──────┬─────┘ │ ┌──────┴─────┐ NBD option │ @@ -160,10 +163,10 @@ the plugin: ┌──────┴─────┐ ┌──────┴─────┐ client #2 │ get_size...

I'm about to add an 'exportname' filter, and in the process, I noticed a few shortcomings in our API. Time to fix those before the 1.22 release locks our API in stone. Overloading .list_exports in order to determine a canonical export name at .open time is awkward; the two uses (answering NBD_OPT_LIST for a full list, vs. remapping a client's "" into a canonical name during .open) are orthogonal enough to warrant separate plugin callbacks. This will also make it easier to...

On Wed, Aug 26, 2020 at 09:16:46PM -0500, Eric Blake wrote: > Rather than defaulting .list_exports to blindly returning "", it is > nicer to have it reflect the result of .default_export. Meanwhile, > language bindings will have a C callback for both .list_exports and > .default_export, even if the underlying script does not, which means > any logic in plugins.c for calli...

On 8/27/20 2:57 AM, Richard W.M. Jones wrote: > On Wed, Aug 26, 2020 at 09:16:46PM -0500, Eric Blake wrote: >> Rather than defaulting .list_exports to blindly returning "", it is >> nicer to have it reflect the result of .default_export. Meanwhile, >> language bindings will have a C callback for both .list_exports and >> .default_export, even if the underlying script does not, which means >> any logic in plu...

...s(-) diff --git a/docs/nbdkit-plugin.pod b/docs/nbdkit-plugin.pod index f8e9962a..6553d186 100644 --- a/docs/nbdkit-plugin.pod +++ b/docs/nbdkit-plugin.pod @@ -152,6 +152,9 @@ the plugin: │ preconnect │ │ └──────┬─────┘ │ ┌──────┴─────┐ │ + │list_exports│ │ + └──────┬─────┘ │ + ┌──────┴─────┐ │ │ open │ │ └──────┬─────┘ │ ┌──────┴─────┐ NBD option │ @@ -160,10 +163,10 @@ the plugin: ┌──────┴─────┐ ┌──────┴─────┐ client #2 │ get_size...

Updated proposal, taking into account the default export. Instead of adding a second call, I made a couple of changes to list_exports: (1) If the plugin has a concept of a default export, it should add it as the first element in the exports list. (2) There is a new default_only flag which tells the plugin that the client is trying to request the name of the default export, so the plugin may return only a single ele...

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 ++++ plugins/ocaml/NBDKit.ml | 17 ++++++++ plugins/ocaml/example.ml | 33 ++++++++++----- plugins/ocaml/ocaml.c | 89 ++++++++++++++++++++++++++++++++++++++++ 4 files changed, 138 insertions(+), 10 de...

If you're following nbdkit development upstream you'll have seen that we are still making changes to the .list_exports and related APIs. The current .list_exports API upstream is not how it will look finally. The latest set of proposals was here: https://www.redhat.com/archives/libguestfs/2020-August/thread.html#00330 At the same time I'd like to do an nbdkit 1.22 (stable) release. There are a few reasons f...

...s(-) diff --git a/docs/nbdkit-plugin.pod b/docs/nbdkit-plugin.pod index f8e9962a..7ce89e9e 100644 --- a/docs/nbdkit-plugin.pod +++ b/docs/nbdkit-plugin.pod @@ -152,6 +152,9 @@ the plugin: │ preconnect │ │ └──────┬─────┘ │ ┌──────┴─────┐ │ + │list_exports│ │ + └──────┬─────┘ │ + ┌──────┴─────┐ │ │ open │ │ └──────┬─────┘ │ ┌──────┴─────┐ NBD option │ @@ -160,10 +163,10 @@ the plugin: ┌──────┴─────┐ ┌──────┴─────┐ client #2 │ get_size...

...eletions(-) diff --git a/plugins/eval/nbdkit-eval-plugin.pod b/plugins/eval/nbdkit-eval-plugin.pod index 7126c6de..7e25a01f 100644 --- a/plugins/eval/nbdkit-eval-plugin.pod +++ b/plugins/eval/nbdkit-eval-plugin.pod @@ -108,8 +108,6 @@ features): =item B<is_rotational=>SCRIPT -=item B<list_exports=>SCRIPT - =item B<open=>SCRIPT =item B<pread=>SCRIPT diff --git a/plugins/sh/nbdkit-sh-plugin.pod b/plugins/sh/nbdkit-sh-plugin.pod index 07d90b57..2d802217 100644 --- a/plugins/sh/nbdkit-sh-plugin.pod +++ b/plugins/sh/nbdkit-sh-plugin.pod @@ -266,58 +266,6 @@ with status C<1...

I'm about to add an 'exportname' filter, and in the process, I noticed a few shortcomings in our API. Time to fix those before the 1.22 release locks our API in stone. First, .list_exports needs to know if it is pre- or post-TLS, as that may affect which names are exported. Next, overloading .list_exports to do both NBD_OPT_LIST and mapping "" to a canonical name is proving to be awkward; the canonical mapping is only needed during an NBD_INFO_NAME response to NBD_OPT_GO,...

...f18f..aaec519c 100644 --- a/plugins/ocaml/NBDKit.mli +++ b/plugins/ocaml/NBDKit.mli @@ -51,6 +51,12 @@ type extent = { } (** The type of the extent list returned by [.extents]. *) +type export = { + name : string; + description : string option; +} +(** The type of the export list returned by [.list_exports]. *) + type thread_model = | THREAD_MODEL_SERIALIZE_CONNECTIONS | THREAD_MODEL_SERIALIZE_ALL_REQUESTS @@ -78,10 +84,13 @@ type 'a plugin = { after_fork : (unit -> unit) option; preconnect : (bool -> unit) option; + list_exports : (bool -> bool -> export list) option; +...

...me 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 friends plugins/python/nbdkit-python-plugin.pod | 25 ++++ tests/Makefile.am | 3 + plugins/ocaml/NBDKit.mli | 9 ++ plugins/ocaml/NBDKit.ml | 17 +++ plugins/ocaml/example.ml...

..., 58 insertions(+), 6 deletions(-) I'm playing with code for an initial implementation of this, and quickly ran into a design issue. For plugins, your proposal is straightforward. But for filters, we have several cases: 1. Filter doesn't care about export name, so it passes through .list_exports to the plugin and advertises the plugin's name; then it further passes through the client's export name to .open() 2. Filter is providing its own export names, so it skips the plugin's .list_exports altogether, and eventually calls .open("") to get the plugin's defaul...

...calization - patch 3: support filters as well as plugins - patch 4: new - patch 5: rewrite sh parser, fix testsuite to actually work and cover more cases (now that libnbd.git is fixed) Eric Blake (4): server: Add exports list functions server: Prepare to use export list from plugin log: Add .list_exports support sh, eval: Add .list_exports support Richard W.M. Jones (1): server: Implement list_exports. docs/nbdkit-filter.pod | 92 +++++++++++++++-- docs/nbdkit-plugin.pod | 64 +++++++++++- docs/nbdkit-protocol.pod | 4 +- filters/log/nbdkit-log-fi...

...9 files changed, 107 insertions(+), 21 deletions(-) diff --git a/plugins/eval/nbdkit-eval-plugin.pod b/plugins/eval/nbdkit-eval-plugin.pod index 7126c6de..eed97f11 100644 --- a/plugins/eval/nbdkit-eval-plugin.pod +++ b/plugins/eval/nbdkit-eval-plugin.pod @@ -110,6 +110,8 @@ features): =item B<list_exports=>SCRIPT +=item B<default_export=>SCRIPT + =item B<open=>SCRIPT =item B<pread=>SCRIPT diff --git a/plugins/sh/nbdkit-sh-plugin.pod b/plugins/sh/nbdkit-sh-plugin.pod index 07d90b57..b827b658 100644 --- a/plugins/sh/nbdkit-sh-plugin.pod +++ b/plugins/sh/nbdkit-sh-plugin.pod @...

Exposing .list_exports through to shell scripts makes testing export listing a lot more feasible. The design chosen here is amenable to 'ls -1' or 'find' output provided there are no newlines or whitespace in the files being listed (the user gives up descriptions in that case), while also being flexible...

...being handed next_ops on entry). > --- > @@ -652,6 +661,46 @@ Returning C<0> will allow the connection to continue. If there is an > error or you want to deny the connection, call C<nbdkit_error> with an > error message and return C<-1>. > > +=head2 C<.list_exports> > + > + int list_exports (int readonly, int default_only, > + struct nbdkit_exports *exports); I'm trying to figure out a situation where knowing whether we are running under 'nbdkit -r' (and thus all exports will be read-only) will affect the list adv...

.... However nbdkit (and indeed other servers) could help by having better diagnostics. I wonder if there are extra fields we could be providing to journald. > >+++ b/plugins/ondemand/ondemand.c > > >+/* Because we rewind the exportsdir handle, we need a lock to protect > >+ * list_exports from being called in parallel. > >+ */ > >+static pthread_mutex_t exports_lock = PTHREAD_MUTEX_INITIALIZER; > > An alternative is to diropen() each time .list_exports gets called. > Either way should work, though. diropen == opendir? > I still have some pending patches t...

...sal and starts fleshing it out with enough meat that I was able to test 'nbdkit eval' advertising multiple exports with descriptions paired with 'qemu-nbd --list'. Eric Blake (3): server: Add exports list functions server: Prepare to use export list from plugin sh, eval: Add .list_exports support Richard W.M. Jones (1): server: Implement list_exports. docs/nbdkit-plugin.pod | 57 +++++++++- docs/nbdkit-protocol.pod | 7 +- plugins/eval/nbdkit-eval-plugin.pod | 2 + plugins/sh/nbdkit-sh-plugin.pod | 31 ++++++ include/nbdkit-common.h...