similar to: [PATCH] nbdkit: Talk about Python in the Python plugin

This change is pure refactoring and should have no effect. --- plugins/python/nbdkit-python-plugin.pod | 12 ++-- plugins/python/python.c | 90 +++++-------------------- 2 files changed, 24 insertions(+), 78 deletions(-) diff --git a/plugins/python/nbdkit-python-plugin.pod b/plugins/python/nbdkit-python-plugin.pod index 51e0f57..0fd4dcb 100644 ---

Fairly straightforward, as the code in plugins.c already takes care of necessary .pwrite fallbacks. Simplify similar can_FOO callbacks that were copy-and-pasted while implementing py_can_zero. Signed-off-by: Eric Blake <eblake@redhat.com> --- plugins/python/nbdkit-python-plugin.pod | 7 +++++ plugins/python/python.c | 51 +++++++++++++++++++-------------- tests/test.py

Now that we have FUA support, the C code can call can_fua as frequently as on every write. If the python script has a can_fua, we can avoid doubling the calls into python by caching the per-connection results, done by wrapping the python handle in a C struct. This commit is marked RFC because it might be nicer if the C code implemented the caching for ALL plugins (TODO already mentions that).

On Wed, Apr 11, 2018 at 12:03:42AM -0500, Eric Blake wrote: > Now that we have FUA support, the C code can call can_fua as > frequently as on every write. If the python script has a > can_fua, we can avoid doubling the calls into python by > caching the per-connection results, done by wrapping the > python handle in a C struct. > > This commit is marked RFC because it might

PyObject_CallObject is powerful, but awkward - we have to wrap all arguments into a temporary tuple before using it. Let python do more of the work by using PyObject_CallFunction anywhere that all arguments can be described by a Py_BuildValue() format string, instead of creating one-shot arguments ourselves. In fact, for our py_config(), this makes it easier to not worry about python 2 String vs.

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

--- plugins/python/nbdkit-python-plugin.pod | 22 +++++++++++-- plugins/python/python.c | 41 +++++++++++++++++++++++++ 2 files changed, 61 insertions(+), 2 deletions(-) diff --git a/plugins/python/nbdkit-python-plugin.pod b/plugins/python/nbdkit-python-plugin.pod index 0fd4dcb..2bc4722 100644 --- a/plugins/python/nbdkit-python-plugin.pod +++

Expose support for the FUA flag to pwrite, zero, and trim, as well as a can_fua callback, for use in python plugins. There are some slight semantic differences: the C plugin had to switch to a new API with a single uint32_t flags argument (so we don't have to keep adding new ABI when new flags are added), but in so doing, there is no way to probe whether a C plugin supports FUA flags, so the

From: "Richard W.M. Jones" <rjones@redhat.com> Previously only one handle could be stored, but we will need to store multiple handles when we have filters. The plugin handle is defined as index 0. Filters will use indices > 0. Message-Id: <20180117205356.8699-6-rjones@redhat.com> [eblake: rework for FUA support] Signed-off-by: Eric Blake <eblake@redhat.com> ---

Similar to the previous patch in caching size, we want to avoid calling into the plugin more than once per connection on any of the flag determination callbacks. The following script demonstrates the speedup, where we avoid repeated calls into a slow can_fua. Pre-patch: $ cat script case "$1" in get_size) echo 1m;; can_fua) sleep 1; echo native;; can_write | can_zero |

I'm about to add an 'exportname' filter, and in the process, I noticed a few shortcomings in our API. Having .default_export makes it easy to answer NBD_INFO_NAME in response to a client request during NBD_OPT_GO, but answering NBD_INFO_DESCRIPTION is awkward - there's no guarantee the export name was given with a description in .list_exports. Note, however, that while we map

This tests the Python plugin thoroughly by issuing client commands through libnbd and checking we get the expected results. --- tests/Makefile.am | 13 +-- tests/test-python-plugin.py | 134 ++++++++++++++++++++++++++++ tests/test-python.py | 172 ++++++++++++++++++++++++++++++++++++ tests/test.py | 60 ------------- 4 files changed, 309 insertions(+), 70

nbdkit_debug implicitly prints the plugin name. However this leads to confusing debug messages such as: nbdkit: pattern[1]: debug: prepare nbdkit: pattern[1]: debug: prepare (in this instance, two different prepare functions were called in different filters, but neither filter name was shown). By printing the filter name in the debug message we improve the output: nbdkit: pattern[1]:

The documentation for .can_write and friends mentioned merely that the callback must return a boolean value, or -1 on failure. Historically, we have treated any non-zero value other than -1 as true, and some plugins have sloppily relied on this behavior, including the standalone nbd plugin prior to the use of libnbd in v1.14. But in 1.15.1, we added an assert in our backend code if an enabled

On 11/22/19 1:54 PM, Richard W.M. Jones wrote: > This change is pure refactoring and should have no effect. > --- > plugins/python/nbdkit-python-plugin.pod | 12 ++-- > plugins/python/python.c | 90 +++++-------------------- > 2 files changed, 24 insertions(+), 78 deletions(-) > > diff --git a/plugins/python/nbdkit-python-plugin.pod

Previously only one handle could be stored, but we will need to store multiple handles when we have filters. The plugin handle is defined as index 0. Filters will use indices > 0. --- src/connections.c | 37 ++++++++++++++++++++++++++++++------- src/internal.h | 4 ++-- src/plugins.c | 53 +++++++++++++++++++++++++++-------------------------- 3 files changed, 59 insertions(+), 35

This allows us to add the following callbacks: - can_zero returns boolean - can_fua should print "none", "emulate" or "native" Furthermore the following callbacks are modified in a backwards compatible manner: - pwrite adding flags parameter - trim adding flags parameter This change is not backwards compatible: - zero may_trim

On Mon, Mar 16, 2020 at 10:36:14PM -0500, Eric Blake wrote: > The documentation for .can_write and friends mentioned merely that the > callback must return a boolean value, or -1 on failure. Historically, > we have treated any non-zero value other than -1 as true, and some > plugins have sloppily relied on this behavior, including the > standalone nbd plugin prior to the use of

On Fri, Jan 19, 2018 at 10:45:51AM -0600, Eric Blake wrote: > I'm wondering if we're missing documentation here (and/or in the plugins > document) that if .can_write returns true, the plugin must supply a > .pwrite; likewise for .can_trim implying a .trim, and .can_flush > implying a .flush. It's a strange one. For example if a plugin returns .can_pwrite == 1 but

This allows us to add the following callbacks: - can_zero returns boolean - can_fua should print "none", "emulate" or "native" Furthermore the following callbacks are modified in a backwards compatible manner: - pwrite adding flags parameter - trim adding flags parameter This change is not backwards compatible: - zero may_trim