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(a)redhat.com>
---
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) {