On 2011-07-25 12:45, Richard W.M. Jones wrote: > 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 <jan.kis...@siemens.com> >>>> >>>> -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)
I understand, this is clumsy. Will see if we can do better. > >>> 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. In principle, this is first of all a Rawhide problem. Upstream really can't babysit every distro doing crazy things with arbitrary devel snapshots. These patches were public, and the maintainers had a fair chance to realize that the interface was not yet set in stone. > > Parsing -help output and guesswork isn't scalable, and this is not > exactly the first time that people have complained about this. I agree. That's why we try hard to release stable interfaces and then maintain them. > > (Yes, libvirt and libguestfs do allow callers to mechanically query > their respective APIs for capabilities.) Maybe Anthony's (Liguori) rework of the QEMU config interfaces will provide a better reflections, haven't checked. But for now you need to stick with this model, specifically when you want to maintain all the distro forks. Jan -- Siemens AG, Corporate Technology, CT T DE IT 1 Corporate Competence Center Embedded Linux
