search for: next_funct

...kend_filter *f = container_of (b, struct backend_filter, backend); + void *handle = connection_get_handle (conn, f->backend.i); + + debug ("close"); + + if (f->filter.close) + f->filter.close (handle); + f->backend.next->close (f->backend.next, conn); +} + +/* The next_functions structure contains pointers to backend + * functions. However because these functions are all expecting a + * backend and a connection, we cannot call them directly, but must + * write some next_* functions that unpack the two parameters from a + * single ‘void *nxdata’ struct pointer (‘b_conn...

...nnect (b_h->b, readonly); > } None of the next_*() wrappers use b_h->handle, they all stick to b_h->b. I don't think that matters too much, other than... > @@ -267,101 +266,101 @@ filter_close (struct backend *b, struct connection *conn, void *handle) > > /* The next_functions structure contains pointers to backend > * functions. However because these functions are all expecting a > - * backend and a connection, we cannot call them directly, but must > + * backend and a handle, we cannot call them directly, but must > * write some next_* functions...

The first three patches are identical to: https://www.redhat.com/archives/libguestfs/2018-January/msg00079.html "[PATCH nbdkit v2 0/3] Refactor plugin_* functions into a backend" The rest of the patches add filters using the new filter API previously described here: https://www.redhat.com/archives/libguestfs/2018-January/msg00073.html This needs a lot more testing -- and tests --

...+- > src/Makefile.am | 1 + > src/filters.c | 606 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++ > src/internal.h | 23 ++- > src/main.c | 114 +++++++++-- > src/plugins.c | 11 +- > 7 files changed, 772 insertions(+), 21 deletions(-) > > +/* The next_functions structure contains pointers to backend > + * functions. However because these functions are all expecting a > + * backend and a connection, we cannot call them directly, but must > + * write some next_* functions that unpack the two parameters from a > + * single ‘void *nxdata’ str...

...connection_get_handle (conn, b->i); - debug ("%s: close", b->name); - if (handle && f->filter.close) f->filter.close (handle); - backend_set_handle (b, conn, NULL); - b->next->close (b->next, conn); + backend_close (b->next, conn); } /* The next_functions structure contains pointers to backend diff --git a/server/plugins.c b/server/plugins.c index 9b44c548..727fb0e0 100644 --- a/server/plugins.c +++ b/server/plugins.c @@ -273,12 +273,8 @@ plugin_close (struct backend *b, struct connection *conn) assert (connection_get_handle (conn, 0)); -...

...incomplete type in the public header) - it would be ABI compatible, and although it would require recompilation, we already state that filter recompilation is par for the course (since only plugins promise API compatibility). But one step at a time; your patch is fine as-is. ACK > /* The next_functions structure contains pointers to backend > - * functions. However because these functions are all expecting a > - * backend and a handle, we cannot call them directly, but must > - * write some next_* functions that unpack the two parameters from a > - * single ‘void *nxdata’ struct...

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

A combination of the work that both Rich and I have been doing lately, where filters use only the new API with flags on every command that the client can send over the wire (we can then add support for more flags in nbdkit without having to add new callbacks, as NBD adds more flags upstream). Eric Blake (4): protocol: Split flags from cmd field in requests backend: Pass flags argument through

...ata = handle; - if (handle && f->filter.close) - f->filter.close (handle); + if (handle && f->filter.close) { + assert (nxdata->b == b->next && nxdata->conn == conn); + f->filter.close (nxdata->handle); + free (nxdata); + } } /* The next_functions structure contains pointers to backend @@ -421,10 +441,11 @@ filter_prepare (struct backend *b, struct connection *conn, void *handle, int readonly) { struct backend_filter *f = container_of (b, struct backend_filter, backend); - struct b_conn nxdata = { .b = b->next, ....

...t_open, b->next, readonly); + handle = f->filter.open (backend_open, b->next, readonly); else if (backend_open (b->next, readonly) == -1) handle = NULL; else @@ -237,171 +220,26 @@ filter_close (struct backend *b, void *handle) f->filter.close (handle); } -/* The next_functions structure contains pointers to backend - * functions. These are only needed for type safety (nxdata is void - * pointer, backend_* functions expect a struct backend * parameter). - * nxdata is a pointer to the next backend in the linked list. - */ - -static int -next_reopen (void *nxdata, int...

...ter, backend); - struct b_h *nxdata = handle; - if (handle && f->filter.close) { - assert (nxdata->b == b->next); - f->filter.close (nxdata->handle); - free (nxdata); - } + if (handle && f->filter.close) + f->filter.close (handle); } /* The next_functions structure contains pointers to backend - * functions. However because these functions are all expecting a - * backend and a handle, we cannot call them directly, but must - * write some next_* functions that unpack the two parameters from a - * single ‘void *nxdata’ struct pointer (‘b_h’). + *...

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

...f->backend.i); + void *handle = connection_get_handle (conn, b->i); debug ("%s: close", f->name); if (f->filter.close) f->filter.close (handle); - f->backend.next->close (f->backend.next, conn); + b->next->close (b->next, conn); } /* The next_functions structure contains pointers to backend @@ -459,15 +453,15 @@ static int filter_prepare (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); - struct b_co...

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

The third patch is a large but mechanical change which gets rid of passing around struct connection * entirely within the server, preferring instead to reference the connection through thread-local storage. I hope this is a gateway to simplifying other parts of the code. Rich.

...kend_filter *f = container_of (b, struct backend_filter, backend); + void *handle = connection_get_handle (conn, f->backend.i); + + debug ("close"); + + if (f->filter.close) + f->filter.close (handle); + f->backend.next->close (f->backend.next, conn); +} + +/* The next_functions structure contains pointers to backend + * functions. However because these functions are all expecting a + * backend and a connection, we cannot call them directly, but must + * write some next_* functions that unpack the two parameters from a + * single ‘void *nxdata’ struct pointer (‘b_conn...

...kend_filter *f = container_of (b, struct backend_filter, backend); + void *handle = connection_get_handle (conn, f->backend.i); + + debug ("close"); + + if (f->filter.close) + f->filter.close (handle); + f->backend.next->close (f->backend.next, conn); +} + +/* The next_functions structure contains pointers to backend + * functions. However because these functions are all expecting a + * backend and a connection, we cannot call them directly, but must + * write some next_* functions that unpack the two parameters from a + * single ‘void *nxdata’ struct pointer (‘b_conn...

...e) { - assert (nxdata->b == b->next && nxdata->conn == conn); + assert (nxdata->b == b->next); f->filter.close (nxdata->handle); free (nxdata); } @@ -267,101 +266,101 @@ filter_close (struct backend *b, struct connection *conn, void *handle) /* The next_functions structure contains pointers to backend * functions. However because these functions are all expecting a - * backend and a connection, we cannot call them directly, but must + * backend and a handle, we cannot call them directly, but must * write some next_* functions that unpack the two pa...

v1 was here: https://www.redhat.com/archives/libguestfs/2020-February/msg00081.html v2 replaces struct connection *conn = GET_CONN; with GET_CONN; which sets conn implicitly and asserts that it is non-NULL. If we actually want to test if conn is non-NULL or behave differently, then you must use threadlocal_get_conn() instead, and some existing uses do that. Rich.

This is still tentative and needs a lot of work, but: - partition filter works, supporting MBR & GPT - prepare and finalize methods fixed - open method can now be changed (allowing readonly flag to be modified) - thread_model can be limited I believe I made most of the changes which were previously suggested in email. I think the only one I didn't was preventing inclusion of both