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.
(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.
Rich.
--
Richard Jones, Virtualization Group, Red Hat
http://people.redhat.com/~rjones
Read my programming and virtualization blog:
http://rwmj.wordpress.com
virt-builder quickly builds VMs from scratch
http://libguestfs.org/virt-builder.1.html