On Wed, Apr 11, 2018 at 12:03:41AM -0500, Eric Blake wrote:
+=item C<can_fua>
+
+(Optional)
+
+ def can_fua(h):
+ # return a boolean
+
+Unlike the C counterpart, the Python callback does not need a
+tri-state return value, because Python introspection is sufficient to
+learn whether callbacks support FUA. Thus, this function only returns
+a bool, which merely controls whether Forced Unit Access (FUA) support
+is advertised to the client on a per-connection basis. If omitted or
+this returns true, FUA support is advertised as native if any of the
+C<pwrite>, C<zero>, or C<trim> callbacks support an optional
parameter
+C<fua>; or as emulated if there is a C<flush> callback.
This is a true description of what the code does ... but it's pretty
complicated.
First of all, if it returns true why don't we just "believe" the
plugin? The callbacks don't have fua optargs, but so what?
And would it be easier both for us and for plugin implementors
if we stuck to the C API here instead of being clever?
Rich.
--
Richard Jones, Virtualization Group, Red Hat
http://people.redhat.com/~rjones
Read my programming and virtualization blog:
http://rwmj.wordpress.com
libguestfs lets you edit virtual machines. Supports shell scripting,
bindings from many languages.
http://libguestfs.org