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@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) {