search for: config_complet

Eric: Did you want to take this one any further? It might be one that we save for > 1.18: https://www.redhat.com/archives/libguestfs/2020-February/thread.html#00206 Another thing I've been thinking about for some time is splitting .config_complete into .config_complete + .get_ready (new name TBD). At the moment .config_complete is both the place where we finish processing config, and also the last chance we get to set things up before the server forks. Of course such a change would not be material — .get_ready would always be run immediate...

On Sat, Feb 22, 2020 at 05:11:01AM -0600, Eric Blake wrote: > On 2/22/20 4:37 AM, Richard W.M. Jones wrote: > >Another thing I've been thinking about for some time is splitting > >.config_complete into .config_complete + .get_ready (new name TBD). > >At the moment .config_complete is both the place where we finish > >processing config, and also the last chance we get to set things up > >before the server forks. Of course such a change would not be > >material — .get...

I like this change. I think we were overloading the config_complete method before to do two different things (complete configuration; do any allocation/housekeeping necessary before we can start serving). The only questions in my mind are whether we want this before 1.18, and whether the name ("get_ready") is a good one. Rich.

...cs/nbdkit-filter.pod b/docs/nbdkit-filter.pod index 07ede47..4f10494 100644 --- a/docs/nbdkit-filter.pod +++ b/docs/nbdkit-filter.pod @@ -126,8 +126,8 @@ which is required. =head1 NEXT PLUGIN -F<nbdkit-filter.h> defines three function types -(C<nbdkit_next_config>, C<nbdkit_next_config_complete>, +F<nbdkit-filter.h> defines four function types (C<nbdkit_next_config>, +C<nbdkit_next_config_complete>, C<nbdkit_ready_to_serve>, C<nbdkit_next_open>) and a structure called C<struct nbdkit_next_ops>. These abstract the next plugin or filter in the chain...

...+ else { + struct filter *f = data; + + debug ("%s: config key=%s, value=%s", f->filename, key, value); + + if (f->filter.config) + if (f->filter.config (key, value, filter_plugin_config, f->next) == -1) + return -1; + return 0; + } } void -plugin_config_complete (void) +plugin_config (const char *key, const char *value) +{ + if (filter_plugin_config (filters, key, value) == -1) + exit (EXIT_FAILURE); +} + +static int +final_plugin_config_complete (void) { assert (dl); debug ("%s: config_complete", filename); if (!plugin.config_...

The tracebacks are compressed into a single line because we're using PyObject_Str, but they are just about usable if not very readable. For example you would see an error like this: nbdkit: error: ./python-exception.py: config_complete: error: ['Traceback (most recent call last):\n', ' File "./python-exception.py", line 54, in config_complete\n raise_error1()\n', ' File "./python-exception.py", line 48, in raise_error1\n raise_error2()\n', ' File "./python-exception.p...

We used traceback.format_exception, returning traceback lines. Join the lines to make the tracebacks more readable. Here is an example traceback: $ ./nbdkit -f -v python tests/python-exception.py ... nbdkit: debug: python: config_complete nbdkit: error: tests/python-exception.py: config_complete: error: Traceback (most recent call last): File "tests/python-exception.py", line 51, in config_complete raise RuntimeError("this is the test string") RuntimeError: this is the test string --- plugins/python/pyt...

Unfortunately this series doesn't work with the real VDDK library :-( I see: nbdkit: debug: vddk: config_complete nbdkit: debug: dlopen shim prefix set to /home/rjones/tmp/vddk-6.7.3/vmware-vix-disklib-distrib/lib64 Then a little bit later during VDDK initialization it fails with: nbdkit: debug: VixDiskLib: Could not load default plugins from /home/rjones/tmp/vddk-6.7.3/vmware-vix-disklib-distrib/lib64/...

...chard W.M. Jones <rjones@redhat.com> wrote: > The tracebacks are compressed into a single line because we're using > PyObject_Str, but they are just about usable if not very readable. > For example you would see an error like this: > > nbdkit: error: ./python-exception.py: config_complete: error: ['Traceback > (most recent call last):\n', ' File "./python-exception.py", line 54, in > config_complete\n raise_error1()\n', ' File "./python-exception.py", > line 48, in raise_error1\n raise_error2()\n', ' File > "...

On 2/17/20 12:17 PM, Richard W.M. Jones wrote: > Unfortunately this series doesn't work with the real VDDK library :-( > > I see: > > nbdkit: debug: vddk: config_complete > nbdkit: debug: dlopen shim prefix set to /home/rjones/tmp/vddk-6.7.3/vmware-vix-disklib-distrib/lib64 > > Then a little bit later during VDDK initialization it fails with: > > nbdkit: debug: VixDiskLib: Could not load default plugins from /home/rjones/tmp/vddk-6.7.3/vmware...

...> https://www.redhat.com/archives/libguestfs/2020-February/thread.html#00206 At this point, I'm thinking save it for post-1.18 (we've already got enough churn on VDDK with LD_LIBRARY_PATH changes). > > Another thing I've been thinking about for some time is splitting > .config_complete into .config_complete + .get_ready (new name TBD). > At the moment .config_complete is both the place where we finish > processing config, and also the last chance we get to set things up > before the server forks. Of course such a change would not be > material — .get_ready would alw...

This is my second attempt at this. The first version (also not working) was here: https://www.redhat.com/archives/libguestfs/2019-October/msg00062.html In part 1/2 I introduce a new .ready_to_serve plugin method which is called after forking and just before accepting any client connection. The idea would be that plugins could start background threads here. However this doesn't work well in

...t nbdkit_next_ops *next_ops, void *nxdata, */ static struct nbdkit_filter filter = { - .name = "ext2", - .longname = "nbdkit ext2 filter", - .load = ext2_load, - .unload = ext2_unload, - .config = ext2_config, - .config_complete = ext2_config_complete, - .config_help = ext2_config_help, - .thread_model = ext2_thread_model, - .open = ext2_open, - .prepare = ext2_prepare, - .close = ext2_close, - .can_fua = ext2_can_fua, - .can_cache = ext2_can_cache,...

...-) diff --git a/docs/nbdkit-filter.pod b/docs/nbdkit-filter.pod index 00f8e70d..510781e1 100644 --- a/docs/nbdkit-filter.pod +++ b/docs/nbdkit-filter.pod @@ -128,23 +128,23 @@ which is required. F<nbdkit-filter.h> defines some function types (C<nbdkit_next_config>, C<nbdkit_next_config_complete>, C<nbdkit_next_get_ready>, -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 call...

...tests/test-single-sh.sh | 4 ++++ > 4 files changed, 30 insertions(+), 11 deletions(-) > The patch does not work as intended as currently written: when we invoke /path/to/script config $key $value, we have already set up stdin/stdout to our own pipes [1]. For .config and .config_complete, reading will always see EOF (no other callback needs to interact with the original stdin, and callbacks like .pwrite actually use the pipe for data). If we want to allow a script to read a password from stdin, we need to preserve the original fd to .config and .config_complete rather than p...

Here's my second attempt at a filter API. As before, .config and .config_complete can only call the next->.config or next->.config_complete methods in the chain respectively. The change is with the connected functions (get_size, pread, pwrite, etc.). Here we pass a struct of next functions allowing the filter to call any functions on the plugin, so for example a write c...

Hi Eric, nbdkit 1.16 was released over 3 months ago, and there has been quite a lot of upstream development since then, so it could be about time for a new stable release. Anything in particular that you would like to get in to 1.18? Or anything we've added that you have reservations about supporting long-term? Rich. -- Richard Jones, Virtualization Group, Red Hat

Applies on top of my pending series for the exportname filter, addressing one of the todo's in that cover letter. Eric Blake (2): filters: Add .export_description wrappers ext2: Supply .list_exports and .default_export filters/ext2/nbdkit-ext2-filter.pod | 3 +- tests/Makefile.am | 16 +++- filters/ext2/ext2.c | 125 +++++++++++++++++++---------

On Wednesday, 14 February 2018 18:06:10 CET Eric Blake wrote: > On 02/14/2018 10:53 AM, Pino Toscano wrote: > > Introduce a new helper function to resolve a path name, calling > > nbdkit_error on failure: other than doing what nbdkit_absolute_path > > does, it also checks that the file exists (and thus avoids errors later > > on). To help distinguish it from

...t; */ > > static struct nbdkit_filter filter = { > - .name = "ext2", > - .longname = "nbdkit ext2 filter", > - .load = ext2_load, > - .unload = ext2_unload, > - .config = ext2_config, > - .config_complete = ext2_config_complete, > - .config_help = ext2_config_help, > - .thread_model = ext2_thread_model, > - .open = ext2_open, > - .prepare = ext2_prepare, > - .close = ext2_close, > - .can_fua = ext2_can_fua, > - .c...