search for: default_on

...e choice of export to expose pre-TLS vs. post-TLS may differ, but without a call to .open yet, our just-added nbdkit_is_tls() does not fit our preferred lifecycle, so this has to be a parameter to the new .default_export. We will alter the signature of .list_exports soon; in the meantime, the bool default_only parameter is now ignored. Adding .default_export support to sh/eval is big enough for a separate patch. The ondemand plugin continues to advertise "" (and not "default") in its list of exports, but now reports a canonical name of "default" when connecting to it. T...

Since v1: - patch 1: check size limits - patch 2: better handling of default export name canonicalization - 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

This takes Rich's API proposal 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

...struct backend *b, int readonly); + #endif /* NBDKIT_INTERNAL_H */ diff --git a/server/backend.c b/server/backend.c index 00e65e3c..3e0a1d24 100644 --- a/server/backend.c +++ b/server/backend.c @@ -164,7 +164,7 @@ backend_list_exports (struct backend *b, int readonly, int default_only, { GET_CONN; struct handle *h = get_handle (conn, b->i); - int r; + size_t count; assert (!default_only); /* XXX Switch to is_tls... */ controlpath_debug ("%s: list_exports readonly=%d default_only=%d", @@ -173,14 +173,15 @@ backend_list_exports (struct backend *b, in...

This is a revision of my .default_export work, plus new work on .export_descriptions and a new exportname filter. I think it is now ready to check in. Things I'd still like in 1.22: - the file plugin should implement .list_exports (patch already posted, but it needs rebasing on this series) - the ext2 filter should override .list_exports when in exportname mode - the nbd plugin should be

More patches on the way for improving .list_exports signature and adding .export_description, but this is the promised code showing why nbdkit_string_intern is useful. Patch 4 is somewhat RFC: we could either add new API to take the boilerplate from: foo_config(const char *key, const char *value) { if (strcmp (key, "file") == 0) { CLEANUP_FREE char *tmp = nbdkit_realpath (value);

...ndshake. TLS @@ -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); + +This optional callback is called if the client tries to list the +exports served by the plugin (using C<NBD_OPT_LIST>). If the plugin +does not supply this callback then a single export called C<""> is +returned. The...

.../plugins/sh/nbdkit-sh-plugin.pod +++ b/plugins/sh/nbdkit-sh-plugin.pod @@ -266,58 +266,6 @@ with status C<1>; unrecognized output is ignored. /path/to/script preconnect <readonly> <exportname> -=item C<list_exports> - - /path/to/script list_exports <readonly> <default_only> - -The C<readonly> parameter will be C<true> or C<false>. The -C<default_only> parameter will be C<true> if the caller is only -interested in the canonical name of the default export, or C<false> to -get a full list of export names; the script may safely i...

....pod index bf01db14..f15bdd96 100644 --- a/docs/nbdkit-filter.pod +++ b/docs/nbdkit-filter.pod @@ -339,12 +339,18 @@ an error message and return C<-1>. =head2 C<.list_exports> int (*list_exports) (nbdkit_next_list_exports *next, void *nxdata, - int readonly, int default_only, + int readonly, int is_tls, struct nbdkit_exports *exports); This intercepts the plugin C<.list_exports> method and can be used to filter which exports are advertised. +The C<readonly> parameter matches what is passed to <.preconnect...

...ckend *b, int readonly); > + > #endif /* NBDKIT_INTERNAL_H */ > diff --git a/server/backend.c b/server/backend.c > index 00e65e3c..3e0a1d24 100644 > --- a/server/backend.c > +++ b/server/backend.c > @@ -164,7 +164,7 @@ backend_list_exports (struct backend *b, int readonly, int default_only, > { > GET_CONN; > struct handle *h = get_handle (conn, b->i); > - int r; > + size_t count; > > assert (!default_only); /* XXX Switch to is_tls... */ > controlpath_debug ("%s: list_exports readonly=%d default_only=%d", > @@ -173,14 +173,15 @...

It's been several weeks since I posted v2 (I got distracted by improving libnbd to better test things, which in turn surfaced some major memory leak problems in nbdsh that are now fixed). Many of the patches are minor rebases from v2, with the biggest changes being fallout from: - patch 2: rename nbdkit_add_default_export to nbdkit_use_default_export - overall: this missed 1.22, so update

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.

...t;BOOL> Limit clients to approved exports (default false).\n" \ + "exportname=<NAME> Add an approved export name, may be repeated.\n" \ + +static int +exportname_list_exports (nbdkit_next_list_exports *next, void *nxdata, + int readonly, int default_only, + struct nbdkit_exports *exps) +{ + size_t i; + struct nbdkit_exports *source; + CLEANUP_EXPORTS_FREE struct nbdkit_exports *exps2 = NULL; + + /* default_only is set when nbdkit is trying to resolve "" during + * .open, and not when the client requested NB...

...a/plugins/sh/nbdkit-sh-plugin.pod +++ b/plugins/sh/nbdkit-sh-plugin.pod @@ -266,6 +266,37 @@ with status C<1>; unrecognized output is ignored. /path/to/script preconnect <readonly> <exportname> +=item C<list_exports> + + /path/to/script list_exports <readonly> <default_only> + +The C<readonly> parameter will be C<true> or C<false>. The +C<default_only> parameter will be C<true> if the caller is only +interested in the canonical name of the default export, or C<false> to +get a full list of export names; the script may safely i...

...I need to finish implementing strict mode in .open, and add tests). I also discovered that we really want .list_exports and .open to know when they are used on plaintext vs. tls clients for --tls=on, and we may want to split out a new .default_export callback rather than overloading .list_exports(default_only=true). Ah well, more to play with tomorrow. Eric Blake (4): file: Forbid non-regular, non-block file names file: Add .list_exports support file: Use dirent.dt_type for speed exportname: New filter .../exportname/nbdkit-exportname-filter.pod | 116 +++++++++++ filters/ext2/nbdkit-ext...

...to approved exports (default false).\n" \ > + "exportname=<NAME> Add an approved export name, may be repeated.\n" \ > + > +static int > +exportname_list_exports (nbdkit_next_list_exports *next, void *nxdata, > + int readonly, int default_only, > + struct nbdkit_exports *exps) > +{ > + size_t i; > + struct nbdkit_exports *source; > + CLEANUP_EXPORTS_FREE struct nbdkit_exports *exps2 = NULL; > + > + /* default_only is set when nbdkit is trying to resolve "" during > + * .op...

...a/plugins/sh/nbdkit-sh-plugin.pod +++ b/plugins/sh/nbdkit-sh-plugin.pod @@ -266,6 +266,58 @@ with status C<1>; unrecognized output is ignored. /path/to/script preconnect <readonly> <exportname> +=item C<list_exports> + + /path/to/script list_exports <readonly> <default_only> + +The C<readonly> parameter will be C<true> or C<false>. The +C<default_only> parameter will be C<true> if the caller is only +interested in the canonical name of the default export, or C<false> to +get a full list of export names; the script may safely i...

...m C<open> diff --git a/plugins/sh/methods.h b/plugins/sh/methods.h index 69017fa4..3fd4ef42 100644 --- a/plugins/sh/methods.h +++ b/plugins/sh/methods.h @@ -46,6 +46,7 @@ extern int sh_after_fork (void); extern int sh_preconnect (int readonly); extern int sh_list_exports (int readonly, int default_only, struct nbdkit_exports *exports); +extern const char *sh_default_export (int readonly, int is_tls); extern void *sh_open (int readonly); extern void sh_close (void *handle); extern int64_t sh_get_size (void *handle); diff --git a/plugins/eval/eval.c b/plugins/eval/...

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 element. However it's fine for plugins to ignore this flag. What about plugins that don't have any concept of a default export? This makes...

...@@ 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 advertised by the plugin. But then again, we _do_ pass the readonly...