similar to: [nbdkit PATCH v2] plugin: add and use nbdkit_realpath

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 exist (and thus avoid errors later on). Apply it where an existing path is required, both in nbdkit itself and in plugins. Related to: https://bugzilla.redhat.com/show_bug.cgi?id=1527334 --- docs/nbdkit-plugin.pod | 13

Hi, this is the v3 of my series for nbdkit_realpath; this series adds an extra documentation update to nbdkit_absolute_path, documenting when it can only be used, and then adds nbdkit_realpath. Thanks, Pino Toscano (2): docs: improve documentation of nbdkit_absolute_path plugin: add and use nbdkit_realpath docs/nbdkit-plugin.pod | 24 +++++++++++++++++++++++- include/nbdkit-common.h

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

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 nbdkit_absolute_path, improve the > documentation of the latter. > > Apply it where an

On 02/21/2018 11:13 AM, Pino Toscano wrote: > 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

These plugins have in common that they store either a list of allocated strings or a list of constant strings. Define either string_vector or const_string_vector as appropriate and use it to store these lists. --- plugins/iso/Makefile.am | 1 + plugins/split/Makefile.am | 1 + plugins/floppy/virtual-floppy.h | 7 +++-- plugins/floppy/directory-lfn.c | 35 +++++++++-------------

sscanf is sadly not safe (because it doesn't handle integer overflow correctly), and strto*l functions are a pain to use correctly. Therefore add some functions to hide the pain of parsing integers from the command line. The simpler uses of sscanf and strto*l are replaced. There are still a few where we are using advanced features of sscanf. --- docs/nbdkit-plugin.pod | 48

Should we use attribute((nonnull)) at all? There's a very interesting history of this in libvirt -- try looking at commit eefb881 plus the commits referencing eefb881 -- but it does seem to work for me using recent GCC and Clang. I only did a few functions because annotating them gets old quickly... Rich.

On 02/13/2018 09:44 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 exist (and thus avoid errors later s/exist/exists/ s/avoid/avoids/ > on). > > Apply it where an existing path is required, both in nbdkit itself and > in

On Mon, Sep 23, 2019 at 01:23:28PM -0500, Eric Blake wrote: > > Hopefully it will warn us if uid_t stops being int. (Also > > we're assuming pid_t == int). > > 64-bit mingw has had a long-standing bug that pid_t was declared as > 64-bit, even though getpid() returns a 32-bit 'int'; I wish they'd fix > their headers, but it violates the assumption of pid_t

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

This is #defined as empty at the moment, but it allows the Windows port to define this __declspec(dllexport), which is necessary for symbols to be exported in DLLs. --- include/nbdkit-common.h | 86 ++++++++++++++++++++++++----------------- include/nbdkit-filter.h | 42 +++++++++++++------- include/nbdkit-plugin.h | 6 +-- server/main.c | 2 + 4 files changed, 83 insertions(+), 53

--- lib/Makefile.am | 27 ++ server/Makefile.am | 24 -- server/nbdkit.syms | 28 +-- server/public.c | 459 +--------------------------------- {server => lib}/extents.c | 4 +- lib/parse.c | 341 +++++++++++++++++++++++++ lib/password.c | 152 +++++++++++ lib/path.c | 97 +++++++

I think I understand now that libnbdkit.so won't break the ABI for existing plugins. Does it require that plugins for newer nbdkit use -lnbdkit (which would be a source API break) or would it still be possible to compile without this? I guess as long as plugins do not start using -no-undefined then it would still work, so it wouldn't be a source API break. I had a look into how we might

Differences from v4: Patch 1 is simplified: I realized that since we already use -rdynamic for nbdkit (after all, we WANT our dlopen()d plugins to be able to call our nbdkit_* exports), it is only a matter of adding dlopen to the set of symbols that we export. With that done, there is no separate shared library needed; our dlopen shim is now part of nbdkit proper, and we don't have to tweak

At least the VDDK plugin needs a way to load .so files with a custom directory prepended. Asking the user to set LD_LIBRARY_PATH is too strong (that would leak into the child process created by --run, and makes the user think about issues that we'd rather cover automatically). But overriding dlopen() to make it easier to prepend a directory name under our control requires either a separate

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

On 3/24/20 3:12 PM, Eric Blake wrote: >> (For non-mingw platforms) this breaks the source API promises rather >> seriously, so if I understand your proposal correctly I don't think >> this is a good idea.  It's possibly something we can consider for >> internal plugins, or for the V3 API. > > How does it break API to request that someone link against a

On Thu, Aug 06, 2020 at 09:23:46PM -0500, Eric Blake wrote: > + if (!filename == !directory) { A bit tricksy. In plugins/nbd/nbd.c I used: int c = !!sockname + !!hostname + !!uri + (command.size > 0) + (socket_fd >= 0) + !!raw_cid; /* Check the user passed exactly one connection parameter. */ if (c > 1) { nbdkit_error ("cannot mix Unix ‘socket’, TCP

This is the previous 5/9 patch posted earlier today, split into reviewable chunks. This passes bisection with -x 'make && make check', but I didn't work very hard on the commit messages, so I refer you back to the original patch to explain how it works: https://www.redhat.com/archives/libguestfs/2020-March/msg00248.html Rich.