search for: next_open

...m/archives/libguestfs/2020-February/msg00092.html > --- > server/filters.c | 217 ++++++++++++++++------------------------------- > 1 file changed, 73 insertions(+), 144 deletions(-) > > @@ -216,201 +205,181 @@ plugin_magic_config_key (struct backend *b) > static int > next_open (void *nxdata, int readonly) > { > - struct b_h *b_h = nxdata; > + struct backend *b_next = nxdata; > > - return backend_open (b_h->b, readonly); > + return backend_open (b_next, readonly); > } With this change, 'next_open' and '(int (*)(void *, int))...

The previous patch argued that globally affecting .can_write based on '-r' (the global 'readonly') prevents the ability for a filter to call next_open(nxdata, true) to purposefully write to the plugin, even while advertising .can_write=0 to the client. But it also demonstrated that when a filter passes false to next_open, we were still making needless probes into the plugin, for something the filter won't be using. This patch improves thing...

...ry/msg00092.html > >--- > > server/filters.c | 217 ++++++++++++++++------------------------------- > > 1 file changed, 73 insertions(+), 144 deletions(-) > > > > >@@ -216,201 +205,181 @@ plugin_magic_config_key (struct backend *b) > > static int > > next_open (void *nxdata, int readonly) > > { > >- struct b_h *b_h = nxdata; > >+ struct backend *b_next = nxdata; > >- return backend_open (b_h->b, readonly); > >+ return backend_open (b_next, readonly); > > } > > With this change, 'next_open' and &...

...ilter have to save it off in the filter?  It looks like > protocol-handshake.c is the only caller, and still has everything in > scope at the time. Nope, we can't. It's because the sequence is: backend_open("clientname") outer_filter.open("clientname") next_open("outername") inner_filter.open("outername") next_open("innername") plugin.open("innername") backend_prepare() backend_prepare() backend_prepare() plugin.prepare() inner_filter.prepare() outer_filter.prepare()...

...rn f->filter.preconnect (next_preconnect, &nxdata, readonly); + return f->filter.preconnect (next_preconnect, b->next, readonly); else return b->next->preconnect (b->next, readonly); } @@ -216,201 +205,181 @@ plugin_magic_config_key (struct backend *b) static int next_open (void *nxdata, int readonly) { - struct b_h *b_h = nxdata; + struct backend *b_next = nxdata; - return backend_open (b_h->b, readonly); + return backend_open (b_next, readonly); } static void * filter_open (struct backend *b, int readonly) { struct backend_filter *f = container_o...

On 01/17/2018 02:53 PM, Richard W.M. Jones wrote: > Also implements the --filters parameter. > --- > docs/nbdkit.pod | 21 +- > nbdkit.in | 17 +- > src/Makefile.am | 1 + > src/filters.c | 606 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++ > src/internal.h | 23 ++- > src/main.c | 114 +++++++++-- > src/plugins.c | 11 +- > 7 files

...s.c b/server/filters.c index 78e32bc5..37e8b51e 100644 --- a/server/filters.c +++ b/server/filters.c @@ -205,6 +205,9 @@ filter_open (struct backend *b, struct connection *conn, int readonly) struct b_conn nxdata = { .b = b->next, .conn = conn }; void *handle; + /* Most filters will call next_open first, resulting in + * inner-to-outer ordering. + */ if (f->filter.open) { handle = f->filter.open (next_open, &nxdata, readonly); if (handle == NULL) @@ -225,6 +228,7 @@ filter_close (struct backend *b, struct connection *conn) struct backend_filter *f = container_of...

...rite/.pread/etc. void nbdkit_plugin_close (struct nbdkit_next_ops *next_ops, void *nxdata); which a filter later calls to close its own connection into the underlying plugin. Any plugin that uses these new functions would probably implement a .open that does NOT call next_open(nxdata), because it instead reuses the shared handle that it opened globally. -- Eric Blake, Principal Software Engineer Red Hat, Inc. +1-919-301-3226 Virtualization: qemu.org | libvirt.org

This is a subset of the last half of the larger 9-patch series. The uncontroversial first half of that series is pushed, but here, I tried to reduce the size of the patches by splitting out some of the more complex changes, so that the rest of the changes remaining in the series are more mechanical. In turn, it forced me to write timing tests, which let me spot another spot where we are wasting

I think this is my last round of patches for issues I identified with the retry filter. With this in place, it should be safe to interject another filter in between retry and the plugin. Eric Blake (5): retry: Don't call into closed plugin tests: Refactor test-retry-reopen-fail.sh tests: Enhance retry test to cover failed reopen server: Move prepare/finalize/close recursion to

...s changed, 96 insertions(+), 52 deletions(-) diff --git a/docs/nbdkit-filter.pod b/docs/nbdkit-filter.pod index 55dfab1..5fed7ca 100644 --- a/docs/nbdkit-filter.pod +++ b/docs/nbdkit-filter.pod @@ -131,7 +131,12 @@ C<nbdkit_next_config_complete>, C<nbdkit_next_preconnect>, C<nbdkit_next_open>) and a structure called C<struct nbdkit_next_ops>. These abstract the next plugin or filter in the chain. There is also an opaque pointer C<nxdata> which must be passed along when calling -these functions. +these functions. The value of C<nxdata> passed to C<.open> h...

With our recent cleanups to nxdata, the only remaining difference between functions like backend_open() and next_open() was the signature (one used void*, the other struct backend *); the API is compatible. All of our filters are in-tree, and we don't promise API/ABI stability, but it is still a lot of files to touch, so the simplest solution to avoid the redundant hop through wrapper functions is to change o...

It's confusing to use the same terminology for a single backend as for the linked list of backends. In particular it's often not clear if we're calling the next backend or the whole chain of backends. --- server/internal.h | 14 ++++++++++-- server/connections.c | 20 ++++++++--------- server/locks.c | 2 +- server/main.c

...t 04:31:31PM -0600, Eric Blake wrote: > (I'm also planning on rebasing my > FUA flags on top of your series, since so far it is looking pretty good). I think after some thought I'm going to add a filter.open method which will include a next parameter (actually 2x next parameters, for next_open and nbdkit_next). It's necessary to implement a copy-on-write layer that we can have a read-write filter which enables readonly on the layer below. Thus it needs to call the layer below with open (readonly=1). For the partition filter it makes sense that during the filter open call we can re...

...nbdkit_plugin_close (struct nbdkit_next_ops *next_ops, > void *nxdata); > > which a filter later calls to close its own connection into the > underlying plugin. Any plugin that uses these new functions would > probably implement a .open that does NOT call next_open(nxdata), > because it instead reuses the shared handle that it opened globally. Agreed, except that filters can call this as often as they like. Not sure this actually solves the list_exports problem however since presumably list_exports still happens before open so it woudn't appear in th...

...provide safe dummy content for plaintext > clients without having to rewrite plugins to do so. > > Signed-off-by: Eric Blake <eblake@redhat.com> > --- I got a test working (although it still shows that we are bit awkward until nbdkit makes it easier for filters to skip calling next_open when it wants to) diff --git c/tests/Makefile.am i/tests/Makefile.am index b5ef96a7..dd756723 100644 --- c/tests/Makefile.am +++ i/tests/Makefile.am @@ -1501,6 +1501,10 @@ EXTRA_DIST += \ test-truncate-extents.sh \ $(NULL) +# tlsdummy filter test. +TESTS += test-tlsdummy.sh +EXTRA_DIST +=...

...56 100644 --- a/docs/nbdkit-filter.pod +++ b/docs/nbdkit-filter.pod @@ -127,22 +127,24 @@ which is required. =head1 NEXT PLUGIN F<nbdkit-filter.h> defines some function types (C<nbdkit_next_config>, -C<nbdkit_next_config_complete>, C<nbdkit_next_preconnect>, -C<nbdkit_next_open>) and a structure called C<struct nbdkit_next_ops>. -These abstract the next plugin or filter in the chain. There is also -an opaque pointer C<nxdata> which must be passed along when calling -these functions. The value of C<nxdata> passed to C<.open> has a -stable lifet...

I'm still working on another set of patches to have reopen call .finalize/.prepare (so that another filter can safely appear between retry and the plugin), but for tonight, these are the patches I think are ready to go. Eric Blake (4): retry: Handle can_fua and can_fast_zero changes tests: Test retry with different fua/fast-zero flags server: Close backends if a filter's .open fails

...have already proposed this for inclusion in API V3. We already do this in nbdkit-sh-plugin. For backwards compatibility with existing plugins we'd make nbdkit_export_name() return the export name passed down by the last filter in the chain, and deprecate this function in V3. For filters the next_open field would take the export_name and this would allow filters to modify the export name. nbdkit-tar-filter would take an explicit tar-export-name=<new> parameter to pass a different export name down to the underlying plugin. If the tar filter was implementing its own export name processing...

...readonly) struct b_conn nxdata = { .b = f->backend.next, .conn = conn }; void *handle; - debug ("%s: open readonly=%d", f->filename, readonly); + debug ("%s: open readonly=%d", f->name, readonly); if (f->filter.open) { handle = f->filter.open (next_open, &nxdata, readonly); @@ -239,7 +239,7 @@ filter_close (struct backend *b, struct connection *conn) struct backend_filter *f = container_of (b, struct backend_filter, backend); void *handle = connection_get_handle (conn, f->backend.i); - debug ("close"); + debug ("%s:...