On 04/19/2018 12:40 PM, Richard W.M. Jones wrote: > On Wed, Apr 11, 2018 at 12:03:42AM -0500, Eric Blake wrote: >> Now that we have FUA support, the C code can call can_fua as >> frequently as on every write. If the python script has a >> can_fua, we can avoid doubling the calls into python by >> caching the per-connection results, done by wrapping the >> python handle in a C struct. >> >> This commit is marked RFC because it might be nicer if the C >> code implemented the caching for ALL plugins (TODO already >> mentions that). > > It's not very clear to me (and this applies to all can_* functions) if > it's OK to call them only once per connection. > > I can't think of any argument against that. Is there a potential > meaning for a plugin to "change its mind" during a connection?
Not with our current documentation in nbdkit-plugin.pod: > =item C<.can_write>, C<.get_size> and other option negotiation callbacks > > These are called during option negotiation with the client, but before > any data is served. These callbacks may return different values > across different C<.open> calls, but within a single connection, must > always return the same value; other code in nbdkit may cache the > per-connection value returned rather than using the callback a second > time. And not really in the NBD protocol, either: the option negotiation callbacks are called up front during handshake time, and determine the flags advertised to the client; there is no support in the NBD protocol for runtime changing of the advertised flags. I suppose if the NBD protocol ever DOES add a way to change negotiation features at runtime (an obvious one being the proposal to add an NBD_CMD_RESIZE that affects .get_size; but also perhaps allowing .can_write to toggle between on or off according to other situations), then we'd need to allow those bits of information to change according to callbacks added in response to the NBD protocol. But again, that would be an addition to the API of the plugin contract, so a new enough plugin that wants runtime changing has to opt in to that, which means our existing semantics of per-connection caching (if we implement it) for all existing can_FOO functions would still work as-is on older plugins. -- Eric Blake, Principal Software Engineer Red Hat, Inc. +1-919-301-3266 Virtualization: qemu.org | libvirt.org
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Libguestfs mailing list [email protected] https://www.redhat.com/mailman/listinfo/libguestfs
