| Message ID | 7f847cb5fd7c350e1460df5772c5a0481bc77b3c.1375211373.git.minovotn@redhat.com |
|---|---|
| State | New |
| Headers | show |
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>
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
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) {
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(+)