search for: log_config_complet

...6,12 @@ log_config (nbdkit_next_config *next, void *nxdata, } return 0; } + if (strcmp (key, "logappend") == 0) { + append = nbdkit_parse_bool (value); + if (append < 0) + return -1; + return 0; + } return next (nxdata, key, value); } @@ -86,7 +93,7 @@ log_config_complete (nbdkit_next_config_complete *next, void *nxdata) nbdkit_error ("missing logfile= parameter for the log filter"); return -1; } - logfile = fopen (logfilename, "w"); + logfile = fopen (logfilename, append ? "a" : "w"); if (!logfile) { n...

...@ -75,6 +77,10 @@ log_config (nbdkit_next_config *next, void *nxdata, } return 0; } + if (strcmp (key, "logappend") == 0) { + append = value[0] && (value[0] != '0' || value[1]); + return 0; + } return next (nxdata, key, value); } @@ -86,7 +92,7 @@ log_config_complete (nbdkit_next_config_complete *next, void *nxdata) nbdkit_error ("missing logfile= parameter for the log filter"); return -1; } - logfile = fopen (logfilename, "w"); + logfile = fopen (logfilename, append ? "a" : "w"); if (!logfile) { n...

...void *nxdata) +extentlist_get_ready (nbdkit_next_get_ready *next, void *nxdata, + int thread_model) { parse_extentlist (); diff --git a/filters/log/log.c b/filters/log/log.c index f8da9ad8..6a3a9b14 100644 --- a/filters/log/log.c +++ b/filters/log/log.c @@ -100,7 +100,7 @@ log_config_complete (nbdkit_next_config_complete *next, void *nxdata) /* Open the logfile. */ static int -log_get_ready (nbdkit_next_get_ready *next, void *nxdata) +log_get_ready (nbdkit_next_get_ready *next, void *nxdata, int thread_model) { int fd; diff --git a/filters/rate/rate.c b/filters/rate/rate.c inde...

v2 turned out to be much more involved, as I ended up fixing several things along the way that I noticed while debugging a feature addition. Eric Blake (5): maint: Improve ./nbdkit option parsing main: Saner newline printing during --help utils: Add nbdkit_parse_bool main: Use new bool parser for --tls log: Allow user option of appending to log docs/nbdkit-plugin.pod | 11

...bdkit_next_config *next, void *nxdata, + const char *key, const char *value) +{ + if (strcmp (key, "logfile") == 0) { + free (logfilename); + logfilename = strdup (value); + return 0; + } + return next (nxdata, key, value); +} + +/* Open the logfile. */ +static int +log_config_complete (nbdkit_next_config_complete *next, void *nxdata) +{ + if (logfilename) { + logfile = fopen (logfilename, "w"); + if (!logfile) { + nbdkit_error ("fopen: %m"); + return -1; + } + } + else + logfile = stderr; + + return next (nxdata); +} + +#define log_...

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.

...ext_get_ready *next, void *nxdata, > + int thread_model) > { > parse_extentlist (); > > diff --git a/filters/log/log.c b/filters/log/log.c > index f8da9ad8..6a3a9b14 100644 > --- a/filters/log/log.c > +++ b/filters/log/log.c > @@ -100,7 +100,7 @@ log_config_complete (nbdkit_next_config_complete *next, void *nxdata) > > /* Open the logfile. */ > static int > -log_get_ready (nbdkit_next_get_ready *next, void *nxdata) > +log_get_ready (nbdkit_next_get_ready *next, void *nxdata, int thread_model) > { > int fd; > > diff --git a/f...

...@@ log_cache (struct nbdkit_next_ops *next_ops, void *nxdata, static struct nbdkit_filter filter = { .name = "log", .longname = "nbdkit log filter", - .version = PACKAGE_VERSION, .config = log_config, .config_complete = log_config_complete, .config_help = log_config_help, diff --git a/filters/nocache/nocache.c b/filters/nocache/nocache.c index a3f11984..7ddb84bc 100644 --- a/filters/nocache/nocache.c +++ b/filters/nocache/nocache.c @@ -101,7 +101,6 @@ nocache_cache (struct nbdkit_next_ops *next_ops, void *nxdata, static st...

Here's what I'm currently playing with; I'm not ready to commit anything until I rebase my FUA work on top of this, as I only want to break filter ABI once between releases. Eric Blake (2): backend: Rework internal/filter error return semantics filters: Add log filter TODO | 2 - docs/nbdkit-filter.pod | 84 +++++++-- docs/nbdkit.pod

Patch 3 still needs tests added, but it is at least working from my simple command line tests. Eric Blake (3): server: Implement nbdkit_is_tls for use during .open server: Expose final thread_model to filter's .get_ready tlsdummy: New filter docs/nbdkit-filter.pod | 21 +- docs/nbdkit-plugin.pod | 34 ++- docs/nbdkit-tls.pod

There's enough here to need a review; some of it probably needs backporting to stable-1.12. This probably breaks tests on Haiku or other platforms that have not been as on-the-ball about atomic CLOEXEC; feel free to report issues that arise, and I'll help come up with workarounds (even if we end up leaving a rare fd leak on less-capable systems). Meanwhile, I'm still working on my

Since v1: add the blocksize filter, add testsuite coverage of the log filter, several fixes to the log filter based on what adding tests revealed I'm still working on FUA flag support patches on top of this; the patches should all be committed in the same release, as we want to minimize the number of releases that cause a filter ABI/API bump Eric Blake (3): backend: Rework internal/filter

This is a major rewrite compared to my v1 series, where I've tried a lot harder to ensure that we still accommodate building on Haiku (although I have not actually yet fired up a Haiku VM to try it for myself). I also managed to make the sh plugin fully parallel, on capable platforms. See also my question on patch 10 on whether I've picked the best naming convention. Eric Blake (17):

After more than a month since v2 [1], I've finally got my FUA support series polished. This is all of my outstanding patches, even though some of them were originally posted in separate threads from the original FUA post [2], [3] [1] https://www.redhat.com/archives/libguestfs/2018-January/msg00113.html [2] https://www.redhat.com/archives/libguestfs/2018-January/msg00219.html [3]