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(a)redhat.com>
>
>See also:
>https://www.redhat.com/archives/libguestfs/2020-July/msg00090.html
>Message-Id: <20200722124201.1823468-2-rjones(a)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