All of lore.kernel.org
 help / color / mirror / Atom feed
From: Anthony Liguori <anthony@codemonkey.ws>
To: Eric Blake <eblake@redhat.com>
Cc: Peter Maydell <peter.maydell@linaro.org>,
	Gerd Hoffmann <kraxel@redhat.com>,
	Aurelien Jarno <aurelien@aurel32.net>,
	"qemu-devel@nongnu.org" <qemu-devel@nongnu.org>
Subject: Re: [Qemu-devel] qemu <-> libvirt interaction broken
Date: Tue, 23 Oct 2012 09:28:10 -0500	[thread overview]
Message-ID: <87boftw9dx.fsf@codemonkey.ws> (raw)
In-Reply-To: <50869675.2010204@redhat.com>

Eric Blake <eblake@redhat.com> writes:

> On 10/23/2012 06:47 AM, Anthony Liguori wrote:
>
>>>>
>>>> This change was postponed to after 1.2 was released to
>>>> give libvirt a chance to wean itself off parsing our --help
>>>> output.
>>>
>>> Yea, I know this has been the plan for a long time and I agree that it
>>> is a good move.
>>>
>>> Only problem is that the switch didn't happen yet.  The bits might be
>>> landed in libvirt/master, but there is no release with this yet and thus
>>> libvirt versions using QOM for feature detection didn't find the way yet
>>> into distributions.
>>>
>>> IMO it is a bit early to stop caring about -help output compatibility in
>>> qemu.
>> 
>> It was announced.  There's been plenty of time to adapt.
>> 
>> If you're using QEMU from git, it's reasonable to require libvirt from
>> git IMHO.
>
> Agreed.
>
> That said, distros can ease the pain by backporting the libvirt patches
> for starting qemu from QMP rather than -help into current libvirt
> releases, although that becomes a matter for distros rather than this list.
>
>> 
>> By the time 1.3 goes out, there should be a libvirt release with the
>> necessary support so if your using distro packages, you'll never notice.
>
> Libvirt 1.0.0 will land in early November, and fully supports qemu.git,
> so you are correct that a released libvirt will be available prior to
> qemu 1.3:
> https://www.redhat.com/archives/libvir-list/2012-October/msg00403.html
> Additionally, there will probably be a release candidate in the next 48
> hours, where you can use that tarball (rawhide will most certainly pick
> it up), so the pain of using libvirt.git to develop qemu.git will not
> last much longer.

Excellent, thanks Eric!

Regards,

Anthony Liguori

>
> -- 
> Eric Blake   eblake@redhat.com    +1-919-301-3266
> Libvirt virtualization library http://libvirt.org

      reply	other threads:[~2012-10-23 14:28 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-10-22 13:28 [Qemu-devel] qemu <-> libvirt interaction broken Gerd Hoffmann
2012-10-22 13:51 ` Peter Maydell
2012-10-23  7:03   ` Gerd Hoffmann
2012-10-23  8:19     ` Peter Maydell
2012-10-23  8:41       ` Gerd Hoffmann
2012-10-23 12:47         ` Anthony Liguori
2012-10-23 13:07           ` Eric Blake
2012-10-23 14:28             ` Anthony Liguori [this message]

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=87boftw9dx.fsf@codemonkey.ws \
    --to=anthony@codemonkey.ws \
    --cc=aurelien@aurel32.net \
    --cc=eblake@redhat.com \
    --cc=kraxel@redhat.com \
    --cc=peter.maydell@linaro.org \
    --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.