[libvirt] [PATCH 2/7] qemu: hotplug: Refactor semantics of qemuDomainWaitForDeviceRemoval
Cole Robinson
crobinso at redhat.com
Tue Apr 12 23:19:59 UTC 2016
On 04/05/2016 11:09 AM, Peter Krempa wrote:
> Neither of the callers cares whether the DEVICE_DELETED event isn't
> supported or the event was received. Simplify the code and callers by
> unifying the two values and changing the return value constants so that
> a temporary variable can be omitted.
> ---
> src/qemu/qemu_hotplug.c | 67 +++++++++++++++----------------------------------
> 1 file changed, 20 insertions(+), 47 deletions(-)
>
> diff --git a/src/qemu/qemu_hotplug.c b/src/qemu/qemu_hotplug.c
> index 6c619e9..7317089 100644
> --- a/src/qemu/qemu_hotplug.c
> +++ b/src/qemu/qemu_hotplug.c
> @@ -3351,11 +3351,13 @@ qemuDomainResetDeviceRemoval(virDomainObjPtr vm)
> }
>
> /* Returns:
> - * 0 when DEVICE_DELETED event is unsupported, or we failed to reliably wait
> - * for the event
> - * 1 when DEVICE_DELETED arrived before the timeout and the caller is
> - * responsible for finishing the removal
> - * 2 device removal did not finish in qemuDomainRemoveDeviceWaitTime
> + * 0 DEVICE_DELETED event is supported and removal of the device did not
> + * finish in qemuDomainRemoveDeviceWaitTime
> + *
> + * 1 when the caller is responsible for finishing the device removal:
> + * - DEVICE_DELETED event is unsupported
> + * - DEVICE_DELETED event arrived before the timeout time
> + * - we failed to reliably wait for the event and thus use fallback behavior
> */
Makes sense... return 1 basically means 'removal succeeded OR there's no way
we can tell if it succeeded or not, so just update the XML to assume it did'
ACK
- Cole
More information about the libvir-list
mailing list