similar to: Extending nbdkit to support listing exports

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

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 feature in any existing plugins. If we wanted to do this there seem like two

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

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

On 7/22/20 4:02 AM, Richard W.M. Jones wrote: >> The more I think about it, the more I disagree with disabling this. >> Or, put another way, I think that the _only_ time -e makes sense is >> _when_ you are using --run. Consider: >> >> nbdkit -U - -e foo info --run 'nbdsh -u $uri -c "print(h.pread(3, 0))"' >> nbdkit -U - -e bar info --run

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);

On 7/20/20 9:43 AM, Richard W.M. Jones wrote: > A major missing feature of this library was the ability to list > exports from an NBD server. This implements the feature by adding a > new handle mode and additional functions for querying the list of > export names. > --- > .gitignore | 1 + > examples/Makefile.am | 14

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

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

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

On 7/21/20 12:46 PM, Eric Blake wrote: >> (2) The --run option no longer sets $exportname (to -e) nor puts the >>      export name into the $uri.  However this was always the wrong >>      thing to do since export names are per connection, not per server. >>      Existing --run scripts will see $exportname expand to "" which is >>      most likely what they

The first one is the nastiest - it is an assertion failure caused by a spec-compliant client and introduced by our security fix that was released in 1.14.1. Eric Blake (4): server: Fix regression for NBD_OPT_INFO before NBD_OPT_GO server: Fix back-to-back SET_META_CONTEXT server: Forbid NUL in export and context names server: Fix OPT_GO on different export than SET_META_CONTEXT

Proposal for new APIs to list exports. The general shape of the API can probably best be seen from the examples/list-exports.c example. Rich.

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.

Patch 3 still needs tests added, but it is at least working from my simple command line tests. Eric Blake (3): server: Implement nbdkit_is_tls for use during .open server: Expose final thread_model to filter's .get_ready tlsdummy: New filter docs/nbdkit-filter.pod | 21 +- docs/nbdkit-plugin.pod | 34 ++- docs/nbdkit-tls.pod

On 7/22/20 7:42 AM, Richard W.M. Jones wrote: > 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(-) I'm playing with code for an initial implementation of this, and quickly

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

Well, I'm not quite done (I still want to get nbdinfo to work on a single nbd connection for all cases when reading the heads of the file is not required), but I'm happy with patches 1-11, and 12-13 show where I'm headed for getting NBD_OPT_INFO to work. Posting now to see if some of the earlier patches are ready to commit while I continue working on the latter half. Eric Blake (13):

On Thu, Aug 06, 2020 at 09:23:46PM -0500, Eric Blake wrote: > + if (!filename == !directory) { A bit tricksy. In plugins/nbd/nbd.c I used: int c = !!sockname + !!hostname + !!uri + (command.size > 0) + (socket_fd >= 0) + !!raw_cid; /* Check the user passed exactly one connection parameter. */ if (c > 1) { nbdkit_error ("cannot mix Unix ‘socket’, TCP