Re: [Qemu-devel] [RESEND][PATCH v3] Generalize -machine command line option

[Richard W.M. Jones]

On Mon, Jul 25, 2011 at 12:33:01PM +0200, Jan Kiszka wrote:
> On 2011-07-25 11:41, Richard W.M. Jones wrote:
> > On Sat, Jul 23, 2011 at 12:38:37PM +0200, Jan Kiszka wrote:
> >> From: Jan Kiszka <address@hidden>
> >>
> >> -machine somehow suggests that it selects the machine, but it doesn't.
> >> Fix that before this command is set in stone.
> >>
> >> Actually, -machine should supersede -M and allow to introduce arbitrary
> >> per-machine options to the command line. That will change the internal
> >> realization again, but we will be able to keep the user interface
> >> stable.
> > 
> > This breaks libguestfs which was doing:
> > 
> >   qemu -machine accel=kvm:tcg ...
> > 
> > We are not passing any -M option at all.  We don't particularly care
> > about the machine type since we're not that performance sensitive and
> > we don't need to serialize the machine state.
> > 
> > I have checked, and this works:
> > 
> >   qemu -machine pc,accel=kvm:tcg ...
> > 
> > "pc" is the default, right?  What about for other architectures?
> 
> Yes, pc is the right default. Other arch have other defaults.

So what you're saying is we have to parse qemu -machine \? output by
looking for the string '(default)'?  eg:

$ ./arm-softmmu/qemu-system-arm -machine \?|fgrep '(default)'
integratorcp ARM Integrator/CP (ARM926EJ-S) (default)

$ ./i386-softmmu/qemu -machine \?|fgrep '(default)'
pc-0.14    Standard PC (default)

> > Please add qemu capabilities, so we can reasonably detect what an
> > unknown qemu binary supports and so we don't need to do endless
> > parsing of the -help output and guesswork.
> 
> This syntax was not yet released (but will be with 0.15, so I was
> pushing this). Therefore, nothing was "officially" broken by this patch.
> 
> I'm sorry if you may have released any libguestfs with the transient
> syntax, but my patches were waiting quite a while for being merged since
> the introduction of -machine.

That's an excuse, not a practical solution.  We have to be able to
work with any qemu.  eg. the qemu in current Fedora Rawhide which
supports only -machine accel=, or qemu in other distros which are also
branched from arbitrary git releases, or qemu that people compile
themselves.

Parsing -help output and guesswork isn't scalable, and this is not
exactly the first time that people have complained about this.

(Yes, libvirt and libguestfs do allow callers to mechanically query
their respective APIs for capabilities.)

Rich.

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming blog: http://rwmj.wordpress.com
Fedora now supports 80 OCaml packages (the OPEN alternative to F#)
http://cocan.org/getting_started_with_ocaml_on_red_hat_and_fedora