From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jan Kiszka Subject: Re: qemu-kvm broken after ./configure --disable-kvm Date: Sun, 14 Jun 2009 15:06:59 +0200 Message-ID: <4A34F5F3.3090109@web.de> References: <4A30FBA3.1070404@us.ibm.com> <4A310C58.6050301@web.de> <4A34DB51.3050700@redhat.com> <4A34DE41.7070506@web.de> <4A34DFA8.1060103@redhat.com> <4A34F15D.4000704@web.de> <4A34F3FF.7040605@redhat.com> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigD25AA93D3CB30BFAC1045230" Cc: Beth Kon , Glauber Costa , kvm To: Avi Kivity Return-path: Received: from fmmailgate02.web.de ([217.72.192.227]:33478 "EHLO fmmailgate02.web.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1755793AbZFNNHI (ORCPT ); Sun, 14 Jun 2009 09:07:08 -0400 In-Reply-To: <4A34F3FF.7040605@redhat.com> Sender: kvm-owner@vger.kernel.org List-ID: This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigD25AA93D3CB30BFAC1045230 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Avi Kivity wrote: > Jan Kiszka wrote: >>>> 2. Upstream does not, and it's unclear if it ever will (if we push >>>> recent headers into kvm-kmod, I think there is no urgent need >>>> anymore). At least for code to-be-pushed upstream, we must not >>>> rely in this anyway. >>>> =20 >>> Yes. >>> >>> Adding the headers to kvm-kmod.h is the right thing technically, but >>> something tells me we'll get a lot of failures by people compiling fi= rst >>> and installing later, rather than the sequence needed to make things >>> work: compile and install kvm-kmod, compile and install qemu[-kvm]. = Not >>> all of the failures will be visible at compile time. >>> >>> =20 >> >> That could (and probably should - independent of in-tree headers) be >> caught by making all KVM_CAPs mandatory, ie. check for the latest and >> greatest ones during configure and drop all the #ifdefs from the code.= >> =20 >=20 > Not with out-of-tree headers. qemu-kvm-0.10.x ought to build against > Linux 2.6.27, kvm-kmod-2.6.30, and kvm-91. >=20 > Making all KVM_CAPs mandatory only works if we carry the headers with q= emu. If we continue to carry our own headers, the #ifdefs are pointless. If we don't, the configure checks should issue an overview on all the features that will be missing and give a hint how to resolve this (kvm-kmod...). >=20 >> Whatever the strategy will be, it should be one with the clear goal to= >> converge over the same approach with upstream. >> =20 >=20 > Definitely. In this case I'm still not sure what we want, though. >=20 Maybe a good topic for next Tuesday. Jan --------------enigD25AA93D3CB30BFAC1045230 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (GNU/Linux) Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org iEYEARECAAYFAko09fcACgkQniDOoMHTA+n1RgCfQz8vpj4HRCEVLcTlXeVtJD4X WnAAnj0xMpyniUKzDY7+7Wok4qVfskLv =lWou -----END PGP SIGNATURE----- --------------enigD25AA93D3CB30BFAC1045230--