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 _______________________________________________ Libguestfs mailing list [email protected] https://www.redhat.com/mailman/listinfo/libguestfs
