search for: get_readi

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.

Eric: Did you want to take this one any further? It might be one that we save for > 1.18: https://www.redhat.com/archives/libguestfs/2020-February/thread.html#00206 Another thing I've been thinking about for some time is splitting .config_complete into .config_complete + .get_ready (new name TBD). At the moment .config_complete is both the place where we finish processing config, and

On Sat, Feb 22, 2020 at 05:11:01AM -0600, Eric Blake wrote: > On 2/22/20 4:37 AM, Richard W.M. Jones wrote: > >Another thing I've been thinking about for some time is splitting > >.config_complete into .config_complete + .get_ready (new name TBD). > >At the moment .config_complete is both the place where we finish > >processing config, and also the last chance we get

The next patch wants to add a filter that will prevent DoS attacks from a plaintext client; to be successful, the filter must guarantee that nbdkit did not settle on SERIALIZE_CONNECTIONS. The easiest way to solve this is to expose the final thread model to .get_ready, which is after the point where .config_complete may have altered it, and before any connections are permitted. Signed-off-by:

On Fri, Aug 07, 2020 at 05:00:52PM -0500, Eric Blake wrote: > The next patch wants to add a filter that will prevent DoS attacks > from a plaintext client; to be successful, the filter must guarantee > that nbdkit did not settle on SERIALIZE_CONNECTIONS. The easiest way > to solve this is to expose the final thread model to .get_ready, which > is after the point where

If you have a plugin which either creates background threads itself or uses a library that creates background threads, it turns out you cannot create these in .get_ready (or earlier). The reason is that nbdkit forks when either daemonizing itself or using the --run option, and fork cancels all the background threads in the child process (the daemonized or captive nbdkit). The only good solution

On 8/10/20 8:01 AM, Richard W.M. Jones wrote: > On Fri, Aug 07, 2020 at 05:00:52PM -0500, Eric Blake wrote: >> The next patch wants to add a filter that will prevent DoS attacks >> from a plaintext client; to be successful, the filter must guarantee >> that nbdkit did not settle on SERIALIZE_CONNECTIONS. The easiest way >> to solve this is to expose the final thread

On Mon, Aug 10, 2020 at 08:13:31AM -0500, Eric Blake wrote: > On 8/10/20 8:01 AM, Richard W.M. Jones wrote: > >On Fri, Aug 07, 2020 at 05:00:52PM -0500, Eric Blake wrote: > >>The next patch wants to add a filter that will prevent DoS attacks > >>from a plaintext client; to be successful, the filter must guarantee > >>that nbdkit did not settle on

VDDK plugin + --run was broken because of the following sequence of events: (1) After .config_complete, server redirects stdin/stdout to /dev/null. (2) Server then calls vddk_get_ready which reexecs. (3) We restart the server from the top, but with stdin/stdout redirected to /dev/null. So saved_stdin/saved_stdout save /dev/null. (4) run_command is called which "restores"

When compiling when an older nbdkit is installed, the build would fail because certain symbols such as .get_ready were not defined: ../../src/libguestfs.org/nbdkit/nbdkit.go:541:8: plugin.get_ready undefined (type _Ctype_struct_nbdkit_plugin has no field or method get_ready) This happens because we were using the installed <nbdkit-plugin.h> rather than the local copy. We don't want

On Thu, Apr 23, 2020 at 05:58:25PM +0100, Daniel P. Berrangé wrote: > On Thu, Apr 23, 2020 at 05:55:14PM +0100, Richard W.M. Jones wrote: > > When compiling when an older nbdkit is installed, the build would fail > > because certain symbols such as .get_ready were not defined: > > > > ../../src/libguestfs.org/nbdkit/nbdkit.go:541:8: plugin.get_ready undefined (type

On 4/15/20 11:16 AM, Richard W.M. Jones wrote: > This allows you to copy an environ, while optionally adding extra > (key, value) pairs to it. > --- > common/utils/Makefile.am | 2 + > common/utils/utils.h | 1 + > common/utils/environ.c | 116 +++++++++++++++++++++++++++++++++++++++ > 3 files changed, 119 insertions(+) > > +++ b/common/utils/utils.h

On Tue, Mar 17, 2020 at 06:16:49AM -0500, Eric Blake wrote: > >+static void * > >+tmpdisk_open (int readonly) > >+{ > >+ struct handle *h; > >+ CLEANUP_FREE char *disk = NULL; > >+ const char *tmpdir; > >+ > >+ tmpdir = getenv ("TMPDIR"); > >+ if (!tmpdir) > >+ tmpdir = "/var/tmp"; > > Rather than

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

Version 2: https://www.redhat.com/archives/libguestfs/2020-April/thread.html#00166 Version 3 contains all changes discussed in the previous review. Rich.

On Wed, Apr 15, 2020 at 03:41:06PM -0500, Eric Blake wrote: > On 4/15/20 11:16 AM, Richard W.M. Jones wrote: > >This allows you to copy an environ, while optionally adding extra > >(key, value) pairs to it. > >--- > > common/utils/Makefile.am | 2 + > > common/utils/utils.h | 1 + > > common/utils/environ.c | 116

Version 1 was here: https://www.redhat.com/archives/libguestfs/2020-April/thread.html#00160 Version 2 side-steps the objections to the first patch by using a well-formed alternate nbdkit.pc file and running ordinary pkg-config against it, so any parsing of --cflags etc will be done by pkg-config. The first patch is essentially the same idea as:

On 6/22/20 10:49 AM, Richard W.M. Jones wrote: > If you have a plugin which either creates background threads itself or > uses a library that creates background threads, it turns out you > cannot create these in .get_ready (or earlier). The reason is that > nbdkit forks when either daemonizing itself or using the --run option, > and fork cancels all the background threads in the

On 6/28/20 4:35 PM, Richard W.M. Jones wrote: > For completeness here are the other ways I investigated: > > * Make generic read, write, zero, trim, extents operations on local > files. The file-like plugins would consume those directly, after > doing any adjustments eg for offset. Unfortunately the operations > that you have to write are not very "pure"

On Thu, Apr 23, 2020 at 05:55:14PM +0100, Richard W.M. Jones wrote: > When compiling when an older nbdkit is installed, the build would fail > because certain symbols such as .get_ready were not defined: > > ../../src/libguestfs.org/nbdkit/nbdkit.go:541:8: plugin.get_ready undefined (type _Ctype_struct_nbdkit_plugin has no field or method get_ready) > > This happens because