On 07/25/2011 05:59 AM, Jan Kiszka wrote:
On 2011-07-25 12:45, Richard W.M. Jones wrote:
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.

Yes, it will, but it doesn't fix this particular. Problem. Until we do a release, we reserve the right to change the syntax of newly introduced command line options.

I don't think any level of introspection changes this.

Regards,

Anthony Liguori


Jan



Reply via email to