From: "Daniel P. Berrange" <berrange@redhat.com>
To: Anthony Liguori <aliguori@us.ibm.com>
Cc: Chris Wright <chrisw@redhat.com>,
libvirt-list@redhat.com, qemu-devel@nongnu.org,
Cole Robinson <crobinso@redhat.com>
Subject: [Qemu-devel] Re: [PATCH] Introduce a -libvirt-caps flag as a stop-gap
Date: Tue, 27 Jul 2010 17:09:42 +0100 [thread overview]
Message-ID: <20100727160942.GQ12387@redhat.com> (raw)
In-Reply-To: <1280246103-6636-1-git-send-email-aliguori@us.ibm.com>
On Tue, Jul 27, 2010 at 10:55:03AM -0500, Anthony Liguori wrote:
> Today libvirt parses -help output to attempt to enumerate capabilities. This
> is very broken and has led to multiple failures. Since libvirt is an important
> management interface to QEMU, we need to do a better job giving them the ability
> to detect what a QEMU executable supports. Right now, we keep fixing up help
> output to appease it's parsing code but this is undesirable.
>
> The Right Solution is to introduce a robust capabilities advertisement that
> enumerates every feature we have. As with most Right Solutions, we don't have
> mergable code today and it's unclear that we'll get there by the next release.
>
> This patch introduces an incremental solution of just spitting out the handful
> of capabilities libvirt is probing for today. This interface will need to
> remain forever but can stop being updated once we have a Right Solution.
This isn't really workable because it only encodes the subset of things
that libvirt currently looks for. If someone comes along with a libvirt
patch for a new features that is already supported by QEMU, but isn't
in this simple output, we're stuck. Adding a one-off special case for
the 0.13 release that we know will be obsolete in 0.14, and obviously
can't be used in qemu < 0.12 is not really a worthwhile use of time.
libvirt has to keep supporting help parsing indefinitely for <= 0.12
releases & expects to support a new extensible & flexible approach for
qemu >= 0.14. Adding a special case that both libvirt & qemu have to
support indefinitely for 0.13 is not really very nice.
Daniel
--
|: Red Hat, Engineering, London -o- http://people.redhat.com/berrange/ :|
|: http://libvirt.org -o- http://virt-manager.org -o- http://deltacloud.org :|
|: http://autobuild.org -o- http://search.cpan.org/~danberr/ :|
|: GnuPG: 7D3B9505 -o- F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :|
next prev parent reply other threads:[~2010-07-27 16:09 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-07-27 15:55 [Qemu-devel] [PATCH] Introduce a -libvirt-caps flag as a stop-gap Anthony Liguori
2010-07-27 16:09 ` Daniel P. Berrange [this message]
2010-07-27 16:38 ` [Qemu-devel] " Anthony Liguori
2010-07-27 17:00 ` Daniel P. Berrange
2010-07-27 17:20 ` Anthony Liguori
2010-07-28 9:53 ` Daniel P. Berrange
2010-07-28 13:44 ` Anthony Liguori
2010-07-27 17:41 ` Chris Wright
2010-07-28 4:52 ` Avi Kivity
2010-07-28 8:57 ` [Qemu-devel] " Amit Shah
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20100727160942.GQ12387@redhat.com \
--to=berrange@redhat.com \
--cc=aliguori@us.ibm.com \
--cc=chrisw@redhat.com \
--cc=crobinso@redhat.com \
--cc=libvirt-list@redhat.com \
--cc=qemu-devel@nongnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.