search for: nbdkit_export

...+extern NBDKIT_DLLEXPORT void nbdkit_shutdown (void); struct nbdkit_extents; -extern int nbdkit_add_extent (struct nbdkit_extents *, +extern NBDKIT_DLLEXPORT int nbdkit_add_extent (struct nbdkit_extents *, uint64_t offset, uint64_t length, uint32_t type); struct nbdkit_exports; -extern int nbdkit_add_export (struct nbdkit_exports *, +extern NBDKIT_DLLEXPORT int nbdkit_add_export (struct nbdkit_exports *, const char *name, const char *description); /* A static non-NULL pointer which can be used when you don't need a diff --git a/incl...

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

...uot;">) 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_add_default_export> to add a single +entry based on the results of C<.default_export>. int nbdkit_add_export (struct nbdkit_export *exports, const char *name, const char *description); + int nbdkit_add_default_export (struct nbdkit_export *exports); The C<name> must be a non-NULL, UTF-8 string between 0 and 4096 bytes in length. Export names must be unique. C<description> is an @@ -725...

...gt;, C<.after_fork>, C<.preconnect>, +C<.list_exports>, and C<.default_export>, which are called outside +the lifetime of a connection. =head2 Next config, open and close @@ -355,7 +355,7 @@ from the layer below. Without error checking it would look like this: struct nbdkit_export e; char *name, *desc; - exports2 = nbdkit_exports_new (default_only); + exports2 = nbdkit_exports_new (); next_list_exports (nxdata, readonly, default_only, exports); for (i = 0; i < nbdkit_exports_count (exports2); ++i) { e = nbdkit_get_export (exports2, i); @@ -376,11 +3...

...hould 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_add_default_export> to add a single > +entry based on the results of C<.default_export>. > > int nbdkit_add_export (struct nbdkit_export *exports, > const char *name, const char *description); > + int nbdkit_add_default_export (struct nbdkit_export *exports); > > The C<name> must be a non-NULL, UTF-8 string between 0 and 4096 bytes > in length. Export names must be unique. C<desc...

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

...kit-common.h index c377e18d..6f580387 100644 --- a/include/nbdkit-common.h +++ b/include/nbdkit-common.h @@ -126,11 +126,6 @@ NBDKIT_EXTERN_DECL (int, nbdkit_add_extent, (struct nbdkit_extents *, uint64_t offset, uint64_t length, uint32_t type)); -struct nbdkit_exports; -NBDKIT_EXTERN_DECL (int, nbdkit_add_export, - (struct nbdkit_exports *, - const char *name, const char *description)); - /* A static non-NULL pointer which can be used when you don't need a * per-connection handle. */ diff --git a/include/nbdkit-fi...

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.

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

...ing 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 NBD protocol defines C<"">...

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

...d @@ -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> and +C<.open>, and may be changed by the filter when calling into the +plugin. The C...

...hould 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 possible ways to do it: (1) Add a call, like nbdkit_export_name, which plugins could call from any connected method to get the current export name, eg: static void * myplugin_open (int readonly) { const char *export = nbdkit_export_name (); ... Do something based on the export name ... } The implementation of this is straightforward. It simply read...

...Y, +# OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT +# OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF +# SUCH DAMAGE. + +include $(top_srcdir)/common-rules.mk + +EXTRA_DIST = nbdkit-exportname-filter.pod + +filter_LTLIBRARIES = nbdkit-exportname-filter.la + +nbdkit_exportname_filter_la_SOURCES = \ + exportname.c \ + $(top_srcdir)/include/nbdkit-filter.h \ + $(NULL) + +nbdkit_exportname_filter_la_CPPFLAGS = \ + -I$(top_srcdir)/include \ + -I$(top_srcdir)/common/include \ + -I$(top_srcdir)/common/utils \ + $(NULL) +nbdkit_exportname_filter_la_CFLAGS = $(WARNINGS_CFLAG...

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

...ion 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 flag to both .preconnect and .open, which are bo...

...ake. TLS @@ -652,6 +661,38 @@ 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, 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 NBD protocol defines C<"">...

...ARISING IN ANY WAY OUT > +# OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF > +# SUCH DAMAGE. > + > +include $(top_srcdir)/common-rules.mk > + > +EXTRA_DIST = nbdkit-exportname-filter.pod > + > +filter_LTLIBRARIES = nbdkit-exportname-filter.la > + > +nbdkit_exportname_filter_la_SOURCES = \ > + exportname.c \ > + $(top_srcdir)/include/nbdkit-filter.h \ > + $(NULL) > + > +nbdkit_exportname_filter_la_CPPFLAGS = \ > + -I$(top_srcdir)/include \ > + -I$(top_srcdir)/common/include \ > + -I$(top_srcdir)/common/utils \ > + $(NULL) > +nbd...

...s. */ static int -send_newstyle_option_reply_exportnames (uint32_t option) +send_newstyle_option_reply_exportnames (uint32_t option, size_t *nr_options) { GET_CONN; struct nbd_fixed_new_option_reply fixed_new_option_reply; - size_t i; + size_t i, list_len; CLEANUP_EXPORTS_FREE struct nbdkit_exports *exps = NULL; + int r; exps = nbdkit_exports_new (); if (exps == NULL) @@ -91,7 +95,8 @@ send_newstyle_option_reply_exportnames (uint32_t option) if (backend_list_exports (top, read_only, exps) == -1) return send_newstyle_option_reply (option, NBD_REP_ERR_PLATFORM); - for (i = 0;...