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