search for: _nbdkit_main

...a bit awkward. The quit flag is still > more awkward because you have to move a lot of quit pipe handling code > into the library which has knock-on effects all over. The other extreme is to have the entire nbdkit engine in libnbdkit.so, plus the addition of a single internal-only callback _nbdkit_main(), then the nbdkit binary becomes a bare-bones: int main (int argc, char *argv[]) { return _nbdkit_main (argc, argv); } at which point you don't have to decide which functionality lives where. After all, you already have a linker script that limits what the main binary exports; which r...

...ag is still > >more awkward because you have to move a lot of quit pipe handling code > >into the library which has knock-on effects all over. > > The other extreme is to have the entire nbdkit engine in > libnbdkit.so, plus the addition of a single internal-only callback > _nbdkit_main(), then the nbdkit binary becomes a bare-bones: > int main (int argc, char *argv[]) { > return _nbdkit_main (argc, argv); > } > > at which point you don't have to decide which functionality lives > where. After all, you already have a linker script that limits what > th...

...a/server/nbdkit.syms b/server/nbdkit.syms > index a67669b7..a516cc0f 100644 > --- a/server/nbdkit.syms > +++ b/server/nbdkit.syms > @@ -54,6 +54,7 @@ > nbdkit_extents_new; > nbdkit_get_extent; > nbdkit_is_tls; > + nbdkit_main; Do we want to export it as _nbdkit_main, to make it obvious that plugins shouldn't try calling it? That's cosmetic if you think it is worth it. -- Eric Blake, Principal Software Engineer Red Hat, Inc. +1-919-301-3226 Virtualization: qemu.org | libvirt.org

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

...> >index a67669b7..a516cc0f 100644 > >--- a/server/nbdkit.syms > >+++ b/server/nbdkit.syms > >@@ -54,6 +54,7 @@ > > nbdkit_extents_new; > > nbdkit_get_extent; > > nbdkit_is_tls; > >+ nbdkit_main; > > Do we want to export it as _nbdkit_main, to make it obvious that > plugins shouldn't try calling it? That's cosmetic if you think it > is worth it. I was a bit in two minds about whether this API should be public or not. Could it be called by other programs? Would it be useful for other programs? Would that just cause...

...gt;> decent .h to put it in, nor is it worth adding a new one just for >> this. So it is fine right here. > > Yup, better suggestions greatfully accepted, but I couldn't see > anywhere obvious. Maybe internal.h? That would work for me. >> Do we want to export it as _nbdkit_main, to make it obvious that >> plugins shouldn't try calling it? That's cosmetic if you think it >> is worth it. > > I was a bit in two minds about whether this API should be public or > not. Could it be called by other programs? Would it be useful for > other progr...

Also available here: https://github.com/rwmjones/nbdkit/tree/2020-windows-mingw This is the port to Windows using native Windows APIs (not MSYS or Cygwin). This patch series is at the point where it basically now works. I can run the server with the memory plugin, and access it remotely using guestfish, creating filesystems and so on without any apparent problems. Nevertheless there are many