On 08/16/2016 11:41 AM, Michal Privoznik wrote:
> We tend to prevent using 'default' in switches. And it is for a
> good reason - control may end up in paths we wouldn't want for
> new values. In this specific case, if qemuBuildHostNetStr is
> called over VIR_DOMAIN_NET_TYPE_VHOSTUSER it would produce
> meaningless output. Fortunately, there no such call yet.
>
> Signed-off-by: Michal Privoznik <mprivozn@xxxxxxxxxx>
> ---
> src/qemu/qemu_command.c | 14 +++++++++++++-
> 1 file changed, 13 insertions(+), 1 deletion(-)
>
I agree in principal, although this function is called by both
qemu_command and qemu_hotplug...
> diff --git a/src/qemu/qemu_command.c b/src/qemu/qemu_command.c
> index e6b3d9d..12f3a6b 100644
> --- a/src/qemu/qemu_command.c
> +++ b/src/qemu/qemu_command.c
> @@ -3660,9 +3660,21 @@ qemuBuildHostNetStr(virDomainNetDefPtr net,
> break;
>
> case VIR_DOMAIN_NET_TYPE_USER:
> - default:
> + case VIR_DOMAIN_NET_TYPE_INTERNAL:
> virBufferAddLit(&buf, "user");
> break;
> +
> + case VIR_DOMAIN_NET_TYPE_HOSTDEV:
> + /* Should have been handled earlier via PCI/USB hotplug code. */
True for the hotplug code - it diverts the HOSTDEV call to
qemuDomainAttachHostDevice... The qemu_command code would not call here
and perhaps even could be considered an error. The problem with
returning NULL here is if it *ever* happened, you'd get that failed for
some reason error.
> + virObjectUnref(cfg);
> + return NULL;
> +
> + case VIR_DOMAIN_NET_TYPE_VHOSTUSER:
> + /* Unsupported yet. */
So, could this too produce meaningless code? Although not called, so I
suppose no big deal. (thinking while typing)...
> + break;
> +
> + case VIR_DOMAIN_NET_TYPE_LAST:
Similarly meaningless code, but would also be an error ostensibly
wouldn't it? Why not move the HOSTDEV down here (with that same
comment)... Generate a real error (invalid type=%d), do the Unref and
return NULL, then call it a good.
John
> + break;
> }
>
> if (vlan >= 0) {
>
--
libvir-list mailing list
libvir-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/libvir-list