Displaying 4 results from an estimated 4 matches for "390972e".
2019 Dec 12
0
[PATCH nbdkit 4/7] server: Allow -D nbdkit.* debug flags for the core server.
...613,9 @@ main (int argc, char *argv[])
free (t);
}
+ /* Apply nbdkit.* flags for the server. */
+ apply_debug_flags (NULL, "nbdkit");
+
/* Check all debug flags were used, and free them. */
free_debug_flags ();
diff --git a/server/nbdkit.syms b/server/nbdkit.syms
index 390972e..96c22c0 100644
--- a/server/nbdkit.syms
+++ b/server/nbdkit.syms
@@ -67,6 +67,8 @@
nbdkit_vdebug;
nbdkit_verror;
+ nbdkit_debug_*;
+
# Everything else is hidden.
local: *;
};
--
2.23.0
2019 Dec 12
9
[PATCH nbdkit 0/7] server: Allow datapath debug messages to be suppressed.
The immediate reason for this patch is to reduce the amount of
debugging in virt-v2v with using the virt-v2v -v option (because this
implies running nbdkit in verbose mode too). Most of the messages are
datapath ones about pread/pwrite requests, and in fact as we've added
more filters on top of nbdkit these messages have got more and more
verbose. However they are not particularly
2019 Sep 23
2
[PATCH nbdkit v2] server: public: Add nbdkit_parse_* functions for safely parsing integers.
...program_name, optarg);
+ if (nbdkit_parse_unsigned ("threads", optarg, &threads) == -1)
exit (EXIT_FAILURE);
- }
/* XXX Worth a maximimum limit on threads? */
break;
diff --git a/server/nbdkit.syms b/server/nbdkit.syms
index d792a5f..390972e 100644
--- a/server/nbdkit.syms
+++ b/server/nbdkit.syms
@@ -49,7 +49,17 @@
nbdkit_get_extent;
nbdkit_nanosleep;
nbdkit_parse_bool;
+ nbdkit_parse_int8_t;
+ nbdkit_parse_int16_t;
+ nbdkit_parse_int32_t;
+ nbdkit_parse_int64_t;
+ nbdkit_parse_int;
nbdkit_parse_size...
2019 Sep 23
2
Re: [PATCH nbdkit] server: public: Add nbdkit_parse_* functions for safely parsing integers.
On Mon, Sep 23, 2019 at 12:05:11PM -0500, Eric Blake wrote:
> > + int nbdkit_parse_long (const char *what, const char *str, long *r);
> > + int nbdkit_parse_unsigned_long (const char *what,
> > + const char *str, unsigned long *r);
>
> Do we really want to encourage the use of parse_long and
> parse_unsigned_long? Those differ between