On Mon, Aug 03, 2020 at 09:31:17AM -0500, Eric Blake wrote:
On 7/31/20 5:22 PM, Eric Blake wrote:
From: "Richard W.M. Jones" <rjones@redhat.com>
See also: https://www.redhat.com/archives/libguestfs/2020-July/msg00090.html Message-Id: <20200722124201.1823468-2-rjones@redhat.com>
For now, this implementation is only for plugins; adding filter support will come later (and probably requires further edits, for the ability for any filter to open up an independent connection to the plugin without being handed next_ops on entry). ---
@@ -652,6 +661,46 @@ Returning C<0> will allow the connection to continue. If there is an error or you want to deny the connection, call C<nbdkit_error> with an error message and return C<-1>.
+=head2 C<.list_exports> + + int list_exports (int readonly, int default_only, + struct nbdkit_exports *exports);
I'm trying to figure out a situation where knowing whether we are running under 'nbdkit -r' (and thus all exports will be read-only) will affect the list advertised by the plugin. But then again, we _do_ pass the readonly flag to both .preconnect and .open, which are bookends around this call. That said, now's the time to decide whether to keep it or to simplify the interface by dropping it, before we bake in a stable release with the API.
A local file which is not writable might be an example of an export that should only be listed when readonly == 1. But ... Unfortunately we only have the -r flag. What would be actually useful information is whether the client wants to connect readonly (ie. it will be sending NBD_FLAG_READ_ONLY) but as that is per-export information we don't know that yet. But I'd say we should probably stick with keeping this flag, along with a stronger disclaimer in the documentation that it might not be as useful as it appears. Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones Read my programming and virtualization blog: http://rwmj.wordpress.com Fedora Windows cross-compiler. Compile Windows programs, test, and build Windows installers. Over 100 libraries supported. http://fedoraproject.org/wiki/MinGW