[Qemu-devel] [PATCH v3] vl.c: Output error on invalid machine type provided

[Qemu-devel] [PATCH v3] vl.c: Output error on invalid machine type provided

[Michal Novotny]

Output error message when user provides the invalid machine type
on the command line. This also saves time to find what issue is
when you upgrade from one version of qemu to another version that
doesn't support required machine type any longer.

Signed-off-by: Michal Novotny <minovotn@redhat.com>

---
The patch is checked using ./scripts/checkpatch.pl script and
also is_help_option() function is being used.
 vl.c | 5 +++++
 1 file changed, 5 insertions(+)

diff --git a/vl.c b/vl.c
index 25b8f2f..dc5241b 100644
--- a/vl.c
+++ b/vl.c
@@ -2671,6 +2671,11 @@ static QEMUMachine *machine_parse(const char *name)
     if (machine) {
         return machine;
     }
+
+    if (name && !is_help_option(name)) {
+        printf("Error: Unsupported machine type '%s'\n", name);
+    }
+
     printf("Supported machines are:\n");
     for (m = first_machine; m != NULL; m = m->next) {
         if (m->alias) {
-- 
1.7.11.7

Re: [Qemu-devel] [PATCH v3] vl.c: Output error on invalid machine type provided

[Eric Blake]

[-- Attachment #1: Type: text/plain, Size: 1609 bytes --]

On 07/30/2013 01:10 PM, Michal Novotny wrote:
> Output error message when user provides the invalid machine type
> on the command line. This also saves time to find what issue is
> when you upgrade from one version of qemu to another version that
> doesn't support required machine type any longer.

I know that has historically happened downstream (for example, Fedora 13
made the mistake of creating a downstream-only fedora-13 machine type
that corresponded roughly to qemu 0.13, it took some further Fedora
patches to libvirt to modernize that name back to an upstream machine
type on an upgrade path before finally being able to drop the downstream
nonsense in Fedora 18 or so).  But isn't upstream qemu supposed to be
guaranteeing command-line stability, in that a newer qemu will never
take away a machine type supported by an older qemu?

But even if the upstream upgrade path never hits this code, your patch
will make it nicer if you _downgrade_ to a version of qemu (still with
this patch, of course) that lacks support for a newer machine.  And the
fact that downstream will take advantage of this even if upstream never
causes the problem on upgrades still justifies using it.

> 
> Signed-off-by: Michal Novotny <minovotn@redhat.com>
> 
> ---
> The patch is checked using ./scripts/checkpatch.pl script and
> also is_help_option() function is being used.
>  vl.c | 5 +++++
>  1 file changed, 5 insertions(+)

Reviewed-by: Eric Blake <eblake@redhat.com>

-- 
Eric Blake   eblake redhat com    +1-919-301-3266
Libvirt virtualization library http://libvirt.org


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 621 bytes --]

Re: [Qemu-devel] [PATCH v3] vl.c: Output error on invalid machine type provided

[Michal Novotny]

On 07/30/2013 09:29 PM, Eric Blake wrote:
> On 07/30/2013 01:10 PM, Michal Novotny wrote:
>> Output error message when user provides the invalid machine type
>> on the command line. This also saves time to find what issue is
>> when you upgrade from one version of qemu to another version that
>> doesn't support required machine type any longer.
> I know that has historically happened downstream (for example, Fedora 13
> made the mistake of creating a downstream-only fedora-13 machine type
> that corresponded roughly to qemu 0.13, it took some further Fedora
> patches to libvirt to modernize that name back to an upstream machine
> type on an upgrade path before finally being able to drop the downstream
> nonsense in Fedora 18 or so).  But isn't upstream qemu supposed to be
> guaranteeing command-line stability, in that a newer qemu will never
> take away a machine type supported by an older qemu?
>
> But even if the upstream upgrade path never hits this code, your patch
> will make it nicer if you _downgrade_ to a version of qemu (still with
> this patch, of course) that lacks support for a newer machine.  And the
> fact that downstream will take advantage of this even if upstream never
> causes the problem on upgrades still justifies using it.

You are correct, Eric. I sent a patch v4 to output error message to
stderr instead so I fixed the commit message.

Thanks,
Michal

-- 
Michal Novotny <minovotn@redhat.com>, RHCE, Red Hat
Virtualization | libvirt-php bindings | php-virt-control.org