[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