similar to: [PATCH nbdkit] Fix --dump-plugin on perl, python and ruby plugins.

On Lua: lua_version=5.3.4 On Perl: perl_version=5.28.0 On Python 2: python_version=2.7.15 On Python 3: python_version=3.7.0 python_pep_384_abi_version=3 On Ruby 2.5.1p57: ruby_api_version=2.5.0 On Tcl: tcl_version=8.6 tcl_patch_level=8.6.8 --- plugins/lua/lua.c | 11 +++++++++++ plugins/perl/perl.c | 4 ++++ plugins/python/python.c | 8 ++++++++

To avoid breaking existing plugins, Python plugins wishing to use version 2 of the API must opt in by declaring: API_VERSION = 2 (Plugins which do not do this are assumed to want API version 1). --- plugins/python/example.py | 14 ++- plugins/python/nbdkit-python-plugin.pod | 56 +++++++----- plugins/python/python.c | 114 ++++++++++++++++++++---- tests/test.py

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

To avoid breaking existing plugins, Python plugins wishing to use version 2 of the API must opt in by declaring: def api_version(): return 2 (Plugins which do not do this are assumed to want API version 1). --- plugins/python/example.py | 15 +++- plugins/python/nbdkit-python-plugin.pod | 61 ++++++++++----- plugins/python/python.c | 100

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

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.

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

Adjust internal functions in preparation for FUA support; although at this point, the default plugins.c can_fua implementation correctly reports python as needing emulation, and we can assert that we aren't seeing a FUA flag. Signed-off-by: Eric Blake <eblake@redhat.com> --- plugins/python/python.c | 17 ++++++++++++----- 1 file changed, 12 insertions(+), 5 deletions(-) diff --git

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

diff -r 3decebe747cb -r fc247aa26d12 plugins/python/python.c --- a/plugins/python/python.c Sat Sep 24 14:46:25 2016 +0200 +++ b/plugins/python/python.c Sat Sep 24 15:03:05 2016 +0200 @@ -437,7 +437,7 @@ Py_DECREF (r); return ret; } - /* No Perl can_write callback, but there's a Perl pwrite callback + /* No Python can_write callback, but there's a Python pwrite callback *

Starting with nbdkit 1.16, Python >= 3.3 will be required. Python 2 reaches end of life on 2020-01-01: https://python3statement.org/ https://pythonclock.org/ Debian oldoldstable and RHEL 7 have Python 3.4 and 3.6 respectively, so it seems pointless to try to support Python < 3.3 which lacked support for PyUnicode_AsUTF8. --- README | 13 +++++++------ configure.ac

On Fri, Nov 22, 2019 at 02:55:31PM -0600, Eric Blake wrote: > On 11/22/19 1:53 PM, Richard W.M. Jones wrote: > >To avoid breaking existing plugins, Python plugins wishing to use > >version 2 of the API must opt in by declaring: > > > > def api_version(): > > return 2 > > > >(Plugins which do not do this are assumed to want API version 1). >

Rather than catching a Python error at runtime when trying to call an object that wasn't callable, just ignore that object up front when loading the plugin. Signed-off-by: Eric Blake <eblake@redhat.com> --- Various examples on calling Python functions from C recommend doing this filtering check. plugins/python/python.c | 5 +++++ 1 file changed, 5 insertions(+) diff --git

--- configure.ac | 8 +++++++ plugins/python/python.c | 51 +++++++++++++++++++++++++++++++++++++++--- tests/Makefile.am | 1 + tests/python-exception.py | 45 +++++++++++++++++++++++++++++++++++++ tests/test-python-exception.sh | 42 ++++++++++++++++++++++++++++++++++ 5 files changed, 144 insertions(+), 3 deletions(-) diff --git a/configure.ac

In preparation for adding other optional flag arguments to the python bindings, start by making the existing 'may_trim' flag to 'zero' be optional. That is, the plugin need not define the parameter if it does not make any semantic difference (ie. if the plugin ignores the hint and never trims); while if the parameter exists, we now pass it as a keyword argument rather than as a

In preparation for adding other optional flag arguments to the python bindings, start by making the existing 'may_trim' flag to 'zero' be optional. That is, the plugin need not define the parameter if it does not make any semantic difference (ie. if the plugin ignores the hint and never trims); while if the parameter exists, we now pass it as a keyword argument rather than as a

On 11/22/19 3:14 PM, Richard W.M. Jones wrote: >>> @@ -54,20 +61,20 @@ def get_size(h): >>> return len(disk) >>> -def pread(h, count, offset): >>> +def pread(h, count, offset, flags): >>> global disk >>> return disk[offset:offset+count] >> >> Do we really want to be passing 'flags' as an integer that the

It is unclear why we were constructing this by hand, but using the following tip we can use PyObject_CallFunction: https://stackoverflow.com/a/21221335 --- plugins/python/python.c | 17 ++++++----------- 1 file changed, 6 insertions(+), 11 deletions(-) diff --git a/plugins/python/python.c b/plugins/python/python.c index 148097f..d65ac45 100644 --- a/plugins/python/python.c +++