On 8/15/19 7:02 AM, Richard W.M. Jones wrote:
>>
>> /* Test if a callback is "null" or not, and set it to null. */
>> -#define CALLBACK_IS_NULL(cb) ((cb).callback == NULL)
>> +#define CALLBACK_IS_NULL(cb) ((cb).callback == NULL && (cb).free ==
NULL)
>
> Semantic change. In generator, you used CALLBACK_IS_NULL() for both
> Closure and OClosure. For OClosure, the new semantics are still
> correct. But for Closure, we now no longer return EFAULT when the
> callback itself is missing but a .free was provided. This changes
> pread_structured and block_status to accept NULL for the callback; which
> is probably not a good idea.
I'm unclear on this. This is the point of the patch - that you can
register a callback which has no callback action but still performs
the free action, and that's not considered a null callback. (It's
considered to be a callback that does nothing and returns 0.) Does
something bad happen to those two calls in this case?
I guess nothing bad happens (for block status, you have basically turned
your command into nothing more than a success/failure check of if the
server replied, but you don't get any status; for pread_structured,
lib/rw.c actually forwards .pread to .pread_structured with
.callback=NULL under the hood). For debug, it means you can register a
notifier for when someone else sets/clears the debug notifier, but still
get the default debug notifications.
Ok, the semantic change doesn't hurt.
--
Eric Blake, Principal Software Engineer
Red Hat, Inc. +1-919-301-3226
Virtualization:
qemu.org |
libvirt.org