search for: test_layers_plugin_config_complet

..._filter_open, .close = test_layers_filter_close, .prepare = test_layers_filter_prepare, diff --git a/tests/test-layers-plugin.c b/tests/test-layers-plugin.c index e9ffd3b..62c0066 100644 --- a/tests/test-layers-plugin.c +++ b/tests/test-layers-plugin.c @@ -72,6 +72,13 @@ test_layers_plugin_config_complete (void) #define test_layers_plugin_config_help "test_layers_plugin_config_help" +static int +test_layers_plugin_ready_to_serve (void) +{ + DEBUG_FUNCTION; + return 0; +} + static void * test_layers_plugin_open (int readonly) { @@ -224,6 +231,7 @@ static struct nbdkit_plugin plug...

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

...er_preconnect, .open = test_layers_filter_open, .close = test_layers_filter_close, diff --git a/tests/test-layers-plugin.c b/tests/test-layers-plugin.c index 10cc6efe..8858bede 100644 --- a/tests/test-layers-plugin.c +++ b/tests/test-layers-plugin.c @@ -72,6 +72,13 @@ test_layers_plugin_config_complete (void) #define test_layers_plugin_config_help "test_layers_plugin_config_help" +static int +test_layers_plugin_get_ready (void) +{ + DEBUG_FUNCTION; + return 0; +} + static int test_layers_plugin_preconnect (int readonly) { @@ -231,6 +238,7 @@ static struct nbdkit_plugin plugin...

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.

...recursing, to show opposite order from .close */ + DEBUG_FUNCTION; + return &handle; } diff --git a/tests/test-layers.c b/tests/test-layers.c index 93b7770c..eac7f152 100644 --- a/tests/test-layers.c +++ b/tests/test-layers.c @@ -282,19 +282,20 @@ main (int argc, char *argv[]) "test_layers_plugin_config_complete", NULL); - /* open methods called in order. */ + /* open methods called in outer-to-inner order, but thanks to next + * pointer, complete in inner-to-outer order. */ log_verify_seen_in_order ("testlayersfilter3: open readonly=0", - "filter3: test_layers_f...

...ith or without * modification, are permitted provided that the following conditions are @@ -36,6 +36,7 @@ #include <stdlib.h> #include <stdint.h> #include <string.h> +#include <unistd.h> #define NBDKIT_API_VERSION 2 #include <nbdkit-plugin.h> @@ -75,7 +76,16 @@ test_layers_plugin_config_complete (void) static int test_layers_plugin_get_ready (void) { + char c = 'X'; DEBUG_FUNCTION; + + /* Test that stdin/stdout have been sanitized */ + if (write (STDOUT_FILENO, &c, 1) != 1 || + read (STDIN_FILENO, &c, 1) != 0) { + nbdkit_error ("unusual stdio behavior...

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

This is what I've been playing with in response to my earlier question about what to do with 'nbdkit -s sh -' (https://www.redhat.com/archives/libguestfs/2020-April/msg00032.html) I'm still open to ideas on a better name, and/or whether adding <stdbool.h> to our public include files is a good idea (if not, returning int instead of bool is tolerable). Eric Blake (2):

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

...6 +79,13 @@ test_layers_plugin_get_ready (void) return 0; } +static int +test_layers_plugin_after_fork (void) +{ + DEBUG_FUNCTION; + return 0; +} + static int test_layers_plugin_preconnect (int readonly) { @@ -239,6 +246,7 @@ static struct nbdkit_plugin plugin = { .config_complete = test_layers_plugin_config_complete, .config_help = test_layers_plugin_config_help, .get_ready = test_layers_plugin_get_ready, + .after_fork = test_layers_plugin_after_fork, .preconnect = test_layers_plugin_preconnect, .open = test_layers_plugin_open, .close = test...