On 8/13/19 10:12 AM, Richard W.M. Jones wrote:
Commit 0904dd113dfa36485623b3c1756dc1aeab3dddeb removed the theoretical possibility of clearing the debug callback from the handle by setting it to NULL (although that was dubious from an API point of view).
This commit adds an explicit way to do this. Another advantage of this is we can internally call this API from other places when we want to clear/free the debug callback. --- generator/generator | 11 +++++++++++ lib/debug.c | 17 ++++++++++++++--- lib/handle.c | 4 +--- 3 files changed, 26 insertions(+), 6 deletions(-)
diff --git a/generator/generator b/generator/generator index 6ccfc5f..d76eeea 100755 --- a/generator/generator +++ b/generator/generator @@ -1013,6 +1013,17 @@ a handle then messages are printed on C<stderr>.
The callback should not call C<nbd_*> APIs on the same handle since it can be called while holding the handle lock and will cause a deadlock."; +}; + + "clear_debug_callback", { + default_call with + args = []; + ret = RErr;
Is RErr the right type, or can we make this a 'never fails' function?
+ shortdesc = "clear the debug callback"; + longdesc = "\ +Remove the debug callback if one was previously associated +with the handle (with C<nbd_set_debug_callback>). If not
s/not/no/
+callback was associated this does nothing."; };
"set_handle_name", { diff --git a/lib/debug.c b/lib/debug.c index ad4d9cb..c1decb2 100644 --- a/lib/debug.c +++ b/lib/debug.c @@ -38,13 +38,24 @@ nbd_unlocked_get_debug (struct nbd_handle *h) return h->debug; }
+int +nbd_unlocked_clear_debug_callback (struct nbd_handle *h) +{ + if (h->debug_callback) + /* ignore return value */ + h->debug_callback (LIBNBD_CALLBACK_FREE, h->debug_data, NULL, NULL); + h->debug_callback = NULL; + h->debug_data = NULL; + return 0; +}
Is it worth returning -1 if no callback was associated, and/or forwarding the return value of callback(FREE, ptr) as the return value of this function? (That's more complicated; I'm also fine with always returning 0 and ignoring the callback(FREE) return). ACK with the typo fix. -- Eric Blake, Principal Software Engineer Red Hat, Inc. +1-919-301-3226 Virtualization: qemu.org | libvirt.org