search for: nbdkit_add_export

...uplicate caching if we did not add this helper > function). I'm a bit confused by how nbdkit_add_default_export() should be used and the documentation additions in this patch definitely need some work, but I'm going to assume it's used like this: my_list_exports (exports) { nbdkit_add_export (exports, "", some_description); /* Mark the most recently added export as the default: */ nbdkit_add_default_export (exports); /* Some other exports: */ nbdkit_add_export (exports, "foo", NULL); nbdkit_add_export (exports, "bar", NULL); } You c...

...>> function). > > I'm a bit confused by how nbdkit_add_default_export() should be used > and the documentation additions in this patch definitely need some > work, but I'm going to assume it's used like this: > > my_list_exports (exports) > { > nbdkit_add_export (exports, "", some_description); > /* Mark the most recently added export as the default: */ > nbdkit_add_default_export (exports); > > /* Some other exports: */ > nbdkit_add_export (exports, "foo", NULL); > nbdkit_add_export (exports,...

...as started with the I<-r> flag on the command line, which is the same value @@ -694,12 +695,13 @@ C<"">). The plugin can ignore this flag and return all exports if it wants. The C<exports> parameter is an opaque object for collecting the list -of exports. Call C<nbdkit_add_export> to add a single export to the -list. If the plugin has a concept of a default export (usually but -not always called C<"">) then it should return that first in the list. +of exports. Call C<nbdkit_add_export> as needed to add specific +exports to the list, or C<nbdkit...

...e default export, or C<false> to -get a full list of export names; the script may safely ignore this -parameter and always provide a full list if desired. - -The first line of output informs nbdkit how to parse the rest of the -output, the remaining lines then supply the inputs of the C -C<nbdkit_add_export> function (see L<nbdkit-plugin(3)>), as follows: - -=over 4 - -=item NAMES - -The remaining output provides one export name per line, and no export -will be given a description. For convenience, this form is also -assumed if the first output line does not match one of the recognized -pars...

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.

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

..." diff --git i/plugins/ocaml/ocaml.c w/plugins/ocaml/ocaml.c index a34f67ca..ea499454 100644 --- i/plugins/ocaml/ocaml.c +++ w/plugins/ocaml/ocaml.c @@ -332,11 +332,12 @@ list_exports_wrapper (int readonly, int is_tls, struct nbdkit_exports *exports) /* Convert exports list into calls to nbdkit_add_export. */ while (rv != Val_int (0)) { - const char *name, *desc; + const char *name, *desc = NULL; v = Field (rv, 0); /* export struct */ name = String_val (Field (v, 0)); - desc = String_val (Field (v, 1)); + if (Is_block (Field (v, 1))) + desc = String_val (Fi...

...rotocol defines C<""> as the default export, so +this is suitable for plugins which ignore the export name and always +serve the same content. See also L</EXPORT NAME> below. + +The C<exports> parameter is an opaque object for collecting the list +of exports. Call C<nbdkit_add_export> to add a single export to the +list. If the plugin has a concept of a default export (usually but +not always called C<"">) then it should return that first in the list. + + int nbdkit_add_export (struct nbdkit_export *exports, + const char *name, const c...

...e default export, or C<false> to +get a full list of export names; the script may safely ignore this +parameter and always provide a full list if desired. + +The first line of output informs nbdkit how to parse the rest of the +output, the remaining lines then supply the inputs of the C +C<nbdkit_add_export> function (see L<nbdkit-plugin(3)>), as follows: + +=over 4 + +=item NAMES + +The remaining output provides one export name per line, and no export +will be given a description. For convenience, this form is also +assumed if the first output line does not match one of the recognized +pars...

Here's changes to the file plugin (which I'm happy with) and a new exportname filter (which is still at RFC stage; 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

...... */ controlpath_debug ("%s: list_exports readonly=%d default_only=%d", b->name, readonly, default_only); assert (h->handle == NULL); assert ((h->state & HANDLE_OPEN) == 0); - if (default_only && h->default_exportname) - return nbdkit_add_export (exports, h->default_exportname, NULL); r = b->list_exports (b, readonly, default_only, exports); if (r == -1) @@ -180,13 +179,34 @@ backend_list_exports (struct backend *b, int readonly, int default_only, else { size_t count = nbdkit_exports_count (exports); controlpath_d...

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

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

...ly valid for a short period of time, basically until the next OCaml allocation in the current thread. > +++ w/plugins/ocaml/ocaml.c > @@ -332,11 +332,12 @@ list_exports_wrapper (int readonly, int > is_tls, struct nbdkit_exports *exports) > > /* Convert exports list into calls to nbdkit_add_export. */ > while (rv != Val_int (0)) { > - const char *name, *desc; > + const char *name, *desc = NULL; > > v = Field (rv, 0); /* export struct */ > name = String_val (Field (v, 0)); > - desc = String_val (Field (v, 1)); > + if (Is_block (Field...

...rotocol defines C<""> as the default export, so +this is suitable for plugins which ignore the export name and always +serve the same content. See also L</EXPORT NAME> below. + +The C<exports> parameter is an opaque object for collecting the list +of exports. Call C<nbdkit_add_export> to add a single export to the +list: + + int nbdkit_add_export (struct nbdkit_export *exports, + const char *name, const char *description); + +The C<name> must be a non-NULL, UTF-8 string no longer than 4096 +bytes. C<description> is an optional description...

...rotocol defines C<""> as the default export, so +this is suitable for plugins which ignore the export name and always +serve the same content. See also L</EXPORT NAME> below. + +The C<exports> parameter is an opaque object for collecting the list +of exports. Call C<nbdkit_add_export> to add a single export to the +list. If the plugin has a concept of a default export (usually but +not always called C<"">) then it should return that first in the list. + + int nbdkit_add_export (struct nbdkit_export *exports, + const char *name, const c...

...rn 0; + } + if (strcmp (key, "exportname-strict") == 0 || + strcmp (key, "exportname_strict") == 0) { + r = nbdkit_parse_bool (value); + if (r == -1) + return -1; + strict = r; + return 0; + } + if (strcmp (key, "exportname") == 0) + return nbdkit_add_export (exports, value, NULL); + return next (nxdata, key, value); +} + +#define exportname_config_help \ + "default-export=<NAME> Canonical name for the \"\" default export.\n" \ + "exportname-list=<BOOL> Whether to advertise exports (default true).\n"...

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

...+get a full list of export names; the script may safely ignore this +parameter and always provide a full list if desired. + +This must print, one per line on stdout, a list of zero or more export +declarations in the format: + + name [description...] + +which correspond to the inputs of the C C<nbdkit_add_export> function +(see L<nbdkit-plugin(3)>). Within the line, the sequence C<\n> is an +escape for a literal newline, and all other uses of backslash escape +the next character. The C<name> field is mandatory; if it begins with +a single quote C<'>, it ends on the first ma...