[Libguestfs] [PATCH nbdkit 0/7] server: Implement NBD_FLAG_CAN_MULTI_CONN.

[Eric Blake]

On 1/5/19 3:22 AM, Richard W.M. Jones wrote:
> On Sat, Jan 05, 2019 at 07:42:56AM +0000, Richard W.M. Jones wrote:
>>> Should the callback include a bool readonly parameter that lets the
>>> filter/plugin know for sure whether it is answering the question on a
>>> read-only connection vs. on a read-write connection, as the answer may
>>> differ between those two?
>>
>> Yes, I think this is a good idea.  Will try that for v2.
> 
> This leads to a subtle layering violation.  I'm assuming that we don't
> pass the same readonly flag that we pass to ‘.open’, but instead we
> would pass conn->readonly which is the computed readonly status after
> considering the whole stack of filters + plugin ‘.can_write’.
> 
> This means that a filter which enables write would cause a plugin
> which only understands readonly connections to be called with
> ‘.can_multi_conn (readonly=0)’.  But a plugin which thinks it is a
> readonly plugin may reasonably assume that it can ignore the readonly
> parameter of ‘.can_multi_conn’ and return true regardless.
> 
> Now having said that I don't think Bad Things can happen, assuming the
> filter also filters ‘.can_multi_conn’ correctly.  But it makes me
> think two things:
> 
> (1) It is possible for plugins to save the readonly flag from ‘.open’
> in the handle.  So we don't need to handle this corner case.

At least the nbd plugin already saves the readonly flag from .open, so
I'm fine if we just document that (1) is the preferred approach.

> 
> (2) Or we might address this by having an nbdkit API function which
> returns the computed readonly status of the whole server.  (Similarly
> we could have one which returns the computed thread model of the whole
> server.)  These functions might be more generally useful than passing
> flags to specific callbacks on a case-by-case basis.  And we can
> caveat them properly in the documentation by noting that these
> functions return the status of the whole stack rather than the current
> layer.

This gets awkward, because filters change the global state (on purpose),
and the plugin should see the way the filter will use it, not the way
the client will use it. Classic example: the cow filter lets the client
see read-write even though the plugin is opened readonly; the plugin's
response should NOT be based on the fact that the client can write.  So
I think that's an argument against (2).

-- 
Eric Blake, Principal Software Engineer
Red Hat, Inc.           +1-919-301-3226
Virtualization:  qemu.org | libvirt.org

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: OpenPGP digital signature
URL: <http://listman.redhat.com/archives/libguestfs/attachments/20190105/809c599b/attachment.sig>