similar to: [PATCH nbdkit] PROPOSED: server: Implement list_exports.

See also: https://www.redhat.com/archives/libguestfs/2020-July/msg00090.html --- docs/nbdkit-plugin.pod | 57 +++++++++++++++++++++++++++++++++++++--- docs/nbdkit-protocol.pod | 7 +++-- 2 files changed, 58 insertions(+), 6 deletions(-) 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 @@

From: "Richard W.M. Jones" <rjones@redhat.com> See also: https://www.redhat.com/archives/libguestfs/2020-July/msg00090.html Message-Id: <20200722124201.1823468-2-rjones@redhat.com> For now, this implementation is only for plugins; adding filter support will come later (and probably requires further edits, for the ability for any filter to open up an independent connection

During the 1.21 development cycle we added support for listing exports. However at the time that 1.22 was released we did not feel the API was sufficiently finalized to commit to in a stable branch. Therefore this new API was removed before 1.22 was released, but the feature continues to be developed upstream and should appear in nbdkit 1.24. Note this also hides the nbdkit*export* functions so

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

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

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

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

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 in the files being listed, while also being flexible enough to support a future format addition if we find ourselves needing a way to express escape sequences or parsing machine-readable code

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 calling .default_export when .list_export is missing would have to be duplicated in each

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 enough to support names or descriptions with arbitrary content. One idea that

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 ++++

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

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

With new-enough libnbd and our new dynamic-export mode, we can grab the export list from the server for replay to the client. Signed-off-by: Eric Blake <eblake@redhat.com> --- plugins/nbd/nbdkit-nbd-plugin.pod | 7 ++ tests/Makefile.am | 2 + plugins/nbd/nbd.c | 53 ++++++++++ tests/test-nbd-dynamic-content.sh | 2 +- tests/test-nbd-dynamic-list.sh

Add a new filter to make it easier to add exports to a plugin that does advertise them, to avoid advertising where a plugin's list might be an information leak, and to alter which export name is used in place of "". I would love to be able to have a strict mode enforcing that .open is called only with an export name that the plugin was willing to advertise, but for that, we'll

On 7/21/20 7:46 AM, Richard W.M. Jones wrote: > Hi Eric, Nir. > > $SUBJECT - it's complicated! Imagine a scenario where we have > extended the file plugin so you can point it at a directory and it > will use the client-supplied export name to select a file to serve. > Also we have extended the tar filter so that you can map tar file > components into export names. You

On Thu, Aug 06, 2020 at 09:23:48PM -0500, Eric Blake wrote: > Add a new filter to make it easier to add exports to a plugin that > does advertise them, to avoid advertising where a plugin's list might does *not* advertise them(?) > be an information leak, and to alter which export name is used in > place of "". > > I would love to be able to have a strict mode

On 9/10/19 5:01 AM, Richard W.M. Jones wrote: > Of course at the moment nbdkit parses the NBD export name option but > doesn't really do anything with it (except logging it). > > I wonder if we should make this available to plugins, in case they > wish to serve different content to different clients based on the > export name. Note I'm not suggesting that we use this

On 8/24/20 7:52 AM, Eric Blake wrote: > 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 >

On Tue, Sep 01, 2020 at 08:41:40AM -0500, Eric Blake wrote: > On 9/1/20 8:25 AM, Eric Blake wrote: > >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