search for: nbdkit_

...o-undefined. Plugins compiled without -lnbdkit (either because they predate the library, or because they specifically did not care about -no-undefined) should still be viable. > > I had a look into how we might implement libnbdkit.so. Some functions > are obviously self-contained (eg. nbdkit_parse_*, nbdkit_realpath, > nbdkit_debug, nbdkit_error, nbdkit_*extents). > > Unfortunately some functions depend themselves on internals > of the server: > > * nbdkit_nanosleep, nbdkit_export_name, nbdkit_peer_name call > threadlocal_get_conn > * nbdkit_set_error c...

...replaced -module -avoid-version -shared with $(SHARED_LDFLAGS), > > adding -no-undefined additionally on mingw. > > Why are we trying to avoid -no-undefined on other platforms? Isn't it because we rely on it, since our plugins need symbols that are undefined at link time such as nbdkit_*? Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones Read my programming and virtualization blog: http://rwmj.wordpress.com virt-p2v converts physical machines to virtual machines. Boot with a live CD or over the network (PXE) and turn machines into KVM guest...

...mode 100644 include/nbdkit-version.h.in diff --git a/configure.ac b/configure.ac index ac8b4ba7..1667cb3f 100644 --- a/configure.ac +++ b/configure.ac @@ -29,7 +29,11 @@ # OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF # SUCH DAMAGE. -AC_INIT([nbdkit], [1.13.9]) +m4_define([NBDKIT_VERSION_MAJOR], [1]) +m4_define([NBDKIT_VERSION_MINOR], [13]) +m4_define([NBDKIT_VERSION_MICRO], [9]) +AC_INIT([nbdkit], + NBDKIT_VERSION_MAJOR.NBDKIT_VERSION_MINOR.NBDKIT_VERSION_MICRO) AC_CONFIG_MACRO_DIR([m4]) m4_ifdef([AC_USE_SYSTEM_EXTENSIONS],[], [m4_define([AC_USE_SYSTEM_EX...

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

...DFLAGS), > >>> adding -no-undefined additionally on mingw. > >> > >> Why are we trying to avoid -no-undefined on other platforms? > > > > Isn't it because we rely on it, since our plugins need symbols that > > are undefined at link time such as nbdkit_*? > > Yes, at the moment they do, but do they need to? We could ship libnbdkit > which provides just the symbols that plugins can link against, and then > link our binary nbdkit against that same library, rather than expecting > our plugins to compile undefined until loaded by our bi...

...iled without -lnbdkit (either because > they predate the library, or because they specifically did not care > about -no-undefined) should still be viable. > > > > >I had a look into how we might implement libnbdkit.so. Some functions > >are obviously self-contained (eg. nbdkit_parse_*, nbdkit_realpath, > >nbdkit_debug, nbdkit_error, nbdkit_*extents). > > > >Unfortunately some functions depend themselves on internals > >of the server: > > > > * nbdkit_nanosleep, nbdkit_export_name, nbdkit_peer_name call > > threadlocal_get_conn...

...ED_LDFLAGS), > >>> adding -no-undefined additionally on mingw. > >> > >>Why are we trying to avoid -no-undefined on other platforms? > > > >Isn't it because we rely on it, since our plugins need symbols that > >are undefined at link time such as nbdkit_*? > > Yes, at the moment they do, but do they need to? We could ship > libnbdkit which provides just the symbols that plugins can link > against, and then link our binary nbdkit against that same library, > rather than expecting our plugins to compile undefined until loaded > by...

This is not intended for v1.14. In fact, we may decide that the second patch is too gross, although the first one still seems like a useful improvement in isolation. I will also point out that all our filters are in-tree, and set the user-controlled field .version to the current release string. We could replace the second patch with a simpler one that just checks ._api_version as an int (as

...bnbdkit.so? If I read the Makefile changes correctly, you went with the former. I'm wondering if we want to add some sort of 'assert(is_initialized)' to all of our public entry functions to ensure that no one is actually trying to use libnbdkit.so without having first gone through nbdkit_private_init; if we did that, then test-public should indeed build from direct files rather than trying to link against libnbdkit.so and bypass the initialization normally done by the nbdkit binary. > +++ b/lib/libnbdkit.syms > @@ -38,6 +38,26 @@ > { > # The functions we want...

...ore like a true out-of-tree plugin that did not opt-in to our library? > +#include <stdio.h> > +#include <stdlib.h> > +#include <string.h> > + > +#include <nbdkit-plugin.h> > + > +static void * > +undefined_open (int readonly) > +{ > + return NBDKIT_HANDLE_NOT_NEEDED; Hmm. I don't see any _use_ of an nbdkit_* function here. It's not enough that this library links without libnbdkit.so, but we need to be testing that when it uses an undefined symbol, such a symbol actually gets provided via the nbdkit binary dlopen()ing this plugin....

...hould make this available to plugins, in case they wish to serve different content to different clients based on the export name. Note I'm not suggesting that we use this feature in any existing plugins. If we wanted to do this there seem like two possible ways to do it: (1) Add a call, like nbdkit_export_name, which plugins could call from any connected method to get the current export name, eg: static void * myplugin_open (int readonly) { const char *export = nbdkit_export_name (); ... Do something based on the export name ... } The implementation of this is straightforward. It simpl...

On Wed, Feb 12, 2020 at 09:38:29AM -0600, Eric Blake wrote: > +#ifdef NBDKIT_INTERNAL > +/* Opaque type encapsulating all information needed for calling into > + * the next filter or plugin. > + */ > +typedef struct backend backend; > +#else > +typedef void backend; > +#endif Is it better to call it something with an nbdkit_* prefix? Although not advis...

...rsion -shared with $(SHARED_LDFLAGS), >>> adding -no-undefined additionally on mingw. >> >> Why are we trying to avoid -no-undefined on other platforms? > > Isn't it because we rely on it, since our plugins need symbols that > are undefined at link time such as nbdkit_*? Yes, at the moment they do, but do they need to? We could ship libnbdkit which provides just the symbols that plugins can link against, and then link our binary nbdkit against that same library, rather than expecting our plugins to compile undefined until loaded by our binary. In other word...

On 3/24/20 2:44 PM, Richard W.M. Jones wrote: >>>> Why are we trying to avoid -no-undefined on other platforms? >>> >>> Isn't it because we rely on it, since our plugins need symbols that >>> are undefined at link time such as nbdkit_*? >> >> Yes, at the moment they do, but do they need to? We could ship >> libnbdkit which provides just the symbols that plugins can link >> against, and then link our binary nbdkit against that same library, >> rather than expecting our plugins to compile undefined un...

...PI 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 implement libnbdkit.so. Some functions are obviously self-contained (eg. nbdkit_parse_*, nbdkit_realpath, nbdkit_debug, nbdkit_error, nbdkit_*extents). Unfortunately some functions depend themselves on internals of the server: * nbdkit_nanosleep, nbdkit_export_name, nbdkit_peer_name call threadlocal_get_conn * nbdkit_set_error calls threadlocal_set_error * nbdkit_shutdo...

...qemu-nbd manual to work out how to read them from an NBD server. Also I don't really see the benefit of this to anyone. The server admin already knows this, and the client doesn't care unless they're looking for a way to attack the server. > And maybe this is an excuse for adding nbdkit_[v]printf_intern()... This could well be useful. Rich. > filters/ext2/ext2.c | 54 ++++++++++++++++++++++---------- > filters/gzip/gzip.c | 40 ++++++++++++++++-------- > filters/partition/partition.c | 58 +++++++++++++++++++++++++---------- > filters/tar/tar.c...

...wish to serve different content to different clients based on the > export name. Note I'm not suggesting that we use this feature in any > existing plugins. > > If we wanted to do this there seem like two possible ways to do it: at least two ways. > > (1) Add a call, like nbdkit_export_name, which plugins could call from > any connected method to get the current export name, eg: > > static void * > myplugin_open (int readonly) > { > const char *export = nbdkit_export_name (); > > ... Do something based on the export name ... > } I would als...

...5 @@ /* nbdkit - * Copyright (C) 2013-2019 Red Hat Inc. + * Copyright (C) 2013-2020 Red Hat Inc. * * Redistribution and use in source and binary forms, with or without * modification, are permitted provided that the following conditions are @@ -49,47 +49,56 @@ extern "C" { #define NBDKIT_ZERO_EMULATE 1 #define NBDKIT_ZERO_NATIVE 2 +#ifdef NBDKIT_INTERNAL +/* Opaque type encapsulating all information needed for calling into + * the next filter or plugin. + */ +typedef struct backend backend; +#else +typedef void backend; +#endif + /* Next ops. */ -typedef int nbdkit_next_config...

...l compilation for mingw is needed for something, then this would be fine. * Unclear why it's necessary to rename nbdkit-common.h -> nbdkit-compat.h ? While this isn't API, it seems we should not rename it unless there's a good reason. * Functions are indirected through struct nbdkit_functions _nbdkit_functions which I guess is necessary because of PE linking (we've had similar problems with PE linking restrictions in other programs). However I wasn't very clear how this actually works, and we cannot break existing Linux binaries, so this needs more thought an...

...ted description for what the client is seeing. Not all clients request the description, but if you are worried about this leaking too much information, it can be silenced with nbdkit-exportname-filter. Signed-off-by: Eric Blake <eblake@redhat.com> --- And maybe this is an excuse for adding nbdkit_[v]printf_intern()... --- filters/ext2/ext2.c | 54 ++++++++++++++++++++++---------- filters/gzip/gzip.c | 40 ++++++++++++++++-------- filters/partition/partition.c | 58 +++++++++++++++++++++++++---------- filters/tar/tar.c | 48 +++++++++++++++++++---------- filte...