On 7/16/19 4:51 AM, Richard W.M. Jones wrote:
Note that nbd_add_close_callback is inconsistent with other closure
types because it passes the user_data parameter after the function.
(This is not caused by the current patch, it was already
inconsistent). We decided that nbd_add_close_callback should be
manually generated and not automatically generated because it should
only be called from C, or perhaps more accurately it is only _needed_
from C (to support cleanup of the non-C bindings), but I don't think
there's any reason not to automatically generate it. If we did
generate it, then it would be an API break because these two
parameters would get swapped around.
I don't mind a separate patch to switch the argument order to make it
consistent, whether or not we decide to generate it (we've already
broken API since the last release due to s/notify/callback/, and we've
already had other API breaks that swapped argument order of int *exit
for consistency, so getting things consistent now is worthwhile).
As for whether to generate it (so that other languages can register a
close callback), I'm on the fence. But in the long run, having our
initial stable API with close callbacks being C only, and a later
release that adds language callbacks because it is generated, should be
upwards compatible.
--
Eric Blake, Principal Software Engineer
Red Hat, Inc. +1-919-301-3226
Virtualization:
qemu.org |
libvirt.org