search for: default_export

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

...1 deletions(-) diff --git a/plugins/eval/nbdkit-eval-plugin.pod b/plugins/eval/nbdkit-eval-plugin.pod index 7126c6de..eed97f11 100644 --- a/plugins/eval/nbdkit-eval-plugin.pod +++ b/plugins/eval/nbdkit-eval-plugin.pod @@ -110,6 +110,8 @@ features): =item B<list_exports=>SCRIPT +=item B<default_export=>SCRIPT + =item B<open=>SCRIPT =item B<pread=>SCRIPT diff --git a/plugins/sh/nbdkit-sh-plugin.pod b/plugins/sh/nbdkit-sh-plugin.pod index 07d90b57..b827b658 100644 --- a/plugins/sh/nbdkit-sh-plugin.pod +++ b/plugins/sh/nbdkit-sh-plugin.pod @@ -315,8 +315,24 @@ export name or descr...

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

...rror) at the same time as listing other exports. Another consideration is that when tls=1, the choice of export to expose pre-TLS vs. post-TLS may differ, but without a call to .open yet, our just-added nbdkit_is_tls() does not fit our preferred lifecycle, so this has to be a parameter to the new .default_export. We will alter the signature of .list_exports soon; in the meantime, the bool default_only parameter is now ignored. Adding .default_export support to sh/eval is big enough for a separate patch. The ondemand plugin continues to advertise "" (and not "default") in its list of...

...if ((filename = nbdkit_string_intern (nbdkit_realpath (value), true)) == NULL) return -1; } Also, more than just the file plugin shares the pattern of copying off a config name where we could simplify or eliminate .unload by interning the string. Eric Blake (5): api: Add .default_export server: Respond to NBD_INFO_NAME request api: Add nbdkit_string_intern helper file: Utilize nbdkit_string_intern sh, eval: Implement .default_export docs/nbdkit-filter.pod | 37 ++++++--- docs/nbdkit-plugin.pod | 66 +++++++++++++++- plugins/eval/nbdkit-eval-...

On 8/25/20 7:21 AM, Richard W.M. Jones wrote: > On Tue, Aug 25, 2020 at 06:16:17AM -0500, Eric Blake wrote: >> On 8/25/20 5:00 AM, Richard W.M. Jones wrote: >> >>>>> +=head2 C<.default_export> >>>>> + >>>>> + const char *default_export (int readonly, int is_tls); >>>> >>>> Oh fun. For some plugins (like ondemand), this is trivial: return a >>>> compile-time constant string. But for others (like sh and eval), >>...

...> - unless they implement .list_exports, in which case the > first export returned is the default export That could be expensive, reading the entire list and throwing away all but the first. I'm now leaning towards two callbacks: .list_exports: compute all exports to advertise .default_export: compute the name to be returned for NBD_OPT_INFO("") and to use by default as $exportname in --run Then, any plugin that wants to advertise a different default export name supplies .default_export, and if .default_export is missing, we supply "" on their behalf. We could a...

On Tue, Aug 25, 2020 at 06:16:17AM -0500, Eric Blake wrote: > On 8/25/20 5:00 AM, Richard W.M. Jones wrote: > > >>>+=head2 C<.default_export> > >>>+ > >>>+ const char *default_export (int readonly, int is_tls); > >> > >>Oh fun. For some plugins (like ondemand), this is trivial: return a > >>compile-time constant string. But for others (like sh and eval), > >>there's a...

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

On 8/25/20 5:00 AM, Richard W.M. Jones wrote: >>> +=head2 C<.default_export> >>> + >>> + const char *default_export (int readonly, int is_tls); >> >> Oh fun. For some plugins (like ondemand), this is trivial: return a >> compile-time constant string. But for others (like sh and eval), >> there's a lifetime issue: this call...

...more sense after the connection > is established, alongside .get_size. > --- > > I obviously need to finish the code to go with this, but here's where > I would like to see the API before we finalize the 1.22 release. > > +++ b/docs/nbdkit-plugin.pod > +=head2 C<.default_export> > + > + const char *default_export (int readonly, int is_tls); Oh fun. For some plugins (like ondemand), this is trivial: return a compile-time constant string. But for others (like sh and eval), there's a lifetime issue: this callback is used _before_ .open, ergo there is no ha...

...is established, alongside .get_size. > >--- > > > >I obviously need to finish the code to go with this, but here's where > >I would like to see the API before we finalize the 1.22 release. > > > > >+++ b/docs/nbdkit-plugin.pod > > >+=head2 C<.default_export> > >+ > >+ const char *default_export (int readonly, int is_tls); > > Oh fun. For some plugins (like ondemand), this is trivial: return a > compile-time constant string. But for others (like sh and eval), > there's a lifetime issue: this callback is used _before_ ....

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 language binding. Better is to ma...

...mpty exports list. On error this function can return C<NULL>. In this case it calls C<nbdkit_error> as required. C<errno> will be set to a suitable @@ -408,6 +412,20 @@ Returns the number of exports in the list. Returns a copy of the C<i>'th export. +=head2 C<.default_export> + + const char *default_export (nbdkit_next_default_export *next, void *nxdata, + int readonly, int is_tls) + +This intercepts the plugin C<.default_export> method and can be used to +alter the canonical export name used in place of the default C<"&quot...

...everal 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 appropriate documentation - libnbd's 'nbdinfo --list' differs in behavior between 1.4.0 and 1.4.1 regarding descriptions, so fix the tests to work for both versions - rebased on top of rewriting test-layers to use libnb...

....list_exports, in which case the > > first export returned is the default export > > That could be expensive, reading the entire list and throwing away > all but the first. I'm now leaning towards two callbacks: > > .list_exports: compute all exports to advertise > .default_export: compute the name to be returned for > NBD_OPT_INFO("") and to use by default as $exportname in --run Maybe I don't understand this, but isn't NBD_OPT_INFO("") explicitly asking for info about the "" export name? In what situation would .default_export eve...

On Wed, Aug 26, 2020 at 09:16:48PM -0500, Eric Blake wrote: > Implementing .default_export with its 'const char *' return is tricky > in the sh plugin: we must return dynamic memory, but must avoid a > use-after-free. And we don't want to change the return type of > .default_export to 'char *', because that would make our choice of > malloc()/free() part...

...s]. *) + type thread_model = | THREAD_MODEL_SERIALIZE_CONNECTIONS | THREAD_MODEL_SERIALIZE_ALL_REQUESTS @@ -78,10 +84,13 @@ type 'a plugin = { after_fork : (unit -> unit) option; preconnect : (bool -> unit) option; + list_exports : (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 : (&...

...s]. *) + type thread_model = | THREAD_MODEL_SERIALIZE_CONNECTIONS | THREAD_MODEL_SERIALIZE_ALL_REQUESTS @@ -78,10 +84,13 @@ type 'a plugin = { after_fork : (unit -> unit) option; preconnect : (bool -> unit) option; + list_exports : (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 : (&...

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