search for: export_descript

...lugin is easier to write if it can just assume the client already passed in the canonical name), we don't need a description until after .open, alongside .get_size. Note that in general, we cannot require the description given (or omitted) in .list_exports to match the description returned by .export_description. Whether a client asks for a listing of available exports is orthogonal to whether a client requests a description on a single export. The recent libnbd 1.4 release has added 'nbd_set_full_info()' as the knob for whether a client will request name and description during NBD_OPT_GO; add...

...diff --git a/filters/ext2/ext2.c b/filters/ext2/ext2.c index 75ac2c4c..7ad4a005 100644 --- a/filters/ext2/ext2.c +++ b/filters/ext2/ext2.c @@ -294,6 +294,25 @@ static int ext2_thread_model (void) return NBDKIT_THREAD_MODEL_SERIALIZE_CONNECTIONS; } +/* Description. */ +static const char * +ext2_export_description (struct nbdkit_next_ops *next_ops, void *nxdata, + void *handle) +{ + struct handle *h = handle; + const char *fname = file ?: h->exportname; + const char *slash = fname[0] == '/' ? "" : "/"; + const char *base = next_ops->export_desc...

...t2.c > index 75ac2c4c..7ad4a005 100644 > --- a/filters/ext2/ext2.c > +++ b/filters/ext2/ext2.c > @@ -294,6 +294,25 @@ static int ext2_thread_model (void) > return NBDKIT_THREAD_MODEL_SERIALIZE_CONNECTIONS; > } > > +/* Description. */ > +static const char * > +ext2_export_description (struct nbdkit_next_ops *next_ops, void *nxdata, > + void *handle) > +{ > + struct handle *h = handle; > + const char *fname = file ?: h->exportname; > + const char *slash = fname[0] == '/' ? "" : "/"; > + const char *b...

...ports : (bool -> bool -> export list) option; + default_export : (bool -> bool -> string) option; open_connection : (bool -> 'a) option; (* required *) close : ('a -> unit) option; get_size : ('a -> int64) option; (* required *) + export_description : ('a -> string) option; can_cache : ('a -> cache_flag) option; can_extents : ('a -> bool) option; diff --git a/plugins/ocaml/NBDKit.ml b/plugins/ocaml/NBDKit.ml index 9ce3bf3e..1d014934 100644 --- a/plugins/ocaml/NBDKit.ml +++ b/plugins/ocaml/NBDKit.ml @@ -53,6 +53,1...

...ports : (bool -> bool -> export list) option; + default_export : (bool -> bool -> string) option; open_connection : (bool -> 'a) option; (* required *) close : ('a -> unit) option; get_size : ('a -> int64) option; (* required *) + export_description : ('a -> string) option; can_cache : ('a -> cache_flag) option; can_extents : ('a -> bool) option; diff --git a/plugins/ocaml/NBDKit.ml b/plugins/ocaml/NBDKit.ml index 9ce3bf3e..1823fc71 100644 --- a/plugins/ocaml/NBDKit.ml +++ b/plugins/ocaml/NBDKit.ml @@ -53,6 +53,1...

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

Fairly straightforward. .list_exports uses the same idiom as .extents for returning an iterable of tuples, with additional support for a bare name rather than a name/desc tuple. .default_export and .export_description are rather easy clients of nbdkit_strdup_intern. Signed-off-by: Eric Blake <eblake at redhat.com> --- plugins/python/nbdkit-python-plugin.pod | 25 ++++ tests/Makefile.am | 3 + plugins/python/python.c | 185 ++++++++++++++++++++---- tests/test-py...

Applies on top of my pending series for the exportname filter, addressing one of the todo's in that cover letter. Eric Blake (2): filters: Add .export_description wrappers ext2: Supply .list_exports and .default_export filters/ext2/nbdkit-ext2-filter.pod | 3 +- tests/Makefile.am | 16 +++- filters/ext2/ext2.c | 125 +++++++++++++++++++--------- filters/gzip/gzip.c | 40 ++++++--- filters/partition...

...fault_export' 002/14:[down] 'api: Add nbdkit_use_default_export' 003/14:[0059] [FC] 'server: Respond to NBD_INFO_NAME request' 004/14:[0021] [FC] 'sh, eval: Implement .default_export' 005/14:[0036] [FC] 'api: Alter .list_exports' 006/14:[0032] [FC] 'api: Add .export_description' 007/14:[0015] [FC] 'exportname: New filter' 008/14:[0049] [FC] 'filters: Add .export_description wrappers' 009/14:[0002] [FC] 'ext2: Supply .list_exports and .default_export' 010/14:[----] [--] 'nbd: Implement .default_export, .export_description' 011/14:[001...

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

...t be altered. + =head2 C<.open> void * (*open) (nbdkit_next_open *next, void *nxdata, @@ -527,6 +545,15 @@ This function is only called once per connection and cached by nbdkit. Similarly, repeated calls to C<next_ops-E<gt>get_size> will return a cached value. +=head2 C<.export_description> + + const char *export_description (struct nbdkit_next_ops *next_ops, + void *nxdata, void *handle); + +This intercepts the plugin C<.export_description> method and can be +used to read or modify the export description that the NBD client +will see. + =...

...sn't do - * much at the moment. + /* For now we send NBD_INFO_NAME if requested, and ignore all + * other info requests (including NBD_INFO_EXPORT if it was + * requested, because we replied already above). + * XXX NBD_INFO_DESCRIPTION is easy once we add .export_description. */ for (i = 0; i < nrinfos; ++i) { memcpy (&info, &data[4 + exportnamelen + 2 + i*2], 2); info = be16toh (info); switch (info) { case NBD_INFO_EXPORT: /* ignore - reply sent above */ break; + case NBD_INFO_NAME:...

On 8/18/20 5:50 AM, Richard W.M. Jones wrote: > This essentially turns the whole of nbdkit into a library. There is a > rump nbdkit program left which simply contains a main() function that > forwards to the nbdkit_main() function in the library. > > The reason for this is to allow nbdkit to be compiled on Windows, > because Windows does not allow shared libraries to contain

...ing a library in the context of a larger multi-threaded app will probably violate those assumptions. > > I don't intend to push any of this stuff until the 1.23 development > branch opens. Fair enough. Then I'd better finish up my work on .list_exports, .default_export, and .export_description to get those done before 1.22. -- Eric Blake, Principal Software Engineer Red Hat, Inc. +1-919-301-3226 Virtualization: qemu.org | libvirt.org

...off another todo bullet point. With this, you can now use the NBD plugin as a transparent passthrough of all export names served by the remote server in both directions (list advertisement server to client, and export name from client to server). Eric Blake (3): nbd: Implement .default_export, .export_description nbd: Add dynamic-export=true option nbd: Implement .list_exports plugins/nbd/nbdkit-nbd-plugin.pod | 30 +++- tests/Makefile.am | 4 + plugins/nbd/nbd.c | 250 +++++++++++++++++++++++++----- tests/test-nbd-dynamic-content.sh | 75 +++++++++ tests/test-nb...

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

This is a cover letter to a series of patches being proposed in tandem to four different projects: - nbd: Document a new NBD_CMD_FLAG_FAST_ZERO command flag - qemu: Implement the flag for both clients and server - libnbd: Implement the flag for clients - nbdkit: Implement the flag for servers, including the nbd passthrough client If you want to test the patches together, I've pushed a