From: Avi Kivity <avi@redhat.com>
To: Jan Kiszka <jan.kiszka@web.de>
Cc: Beth Kon <eak@us.ibm.com>, Glauber Costa <glommer@redhat.com>,
kvm <kvm@vger.kernel.org>
Subject: Re: qemu-kvm broken after ./configure --disable-kvm
Date: Sun, 14 Jun 2009 15:58:39 +0300 [thread overview]
Message-ID: <4A34F3FF.7040605@redhat.com> (raw)
In-Reply-To: <4A34F15D.4000704@web.de>
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.
>>>
>> 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 first
>> 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.
>>
>>
>
> 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.
>
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.
Making all KVM_CAPs mandatory only works if we carry the headers with qemu.
> Whatever the strategy will be, it should be one with the clear goal to
> converge over the same approach with upstream.
>
Definitely. In this case I'm still not sure what we want, though.
--
error compiling committee.c: too many arguments to function
next prev parent reply other threads:[~2009-06-14 12:58 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-06-11 12:42 qemu-kvm broken after ./configure --disable-kvm Beth Kon
2009-06-11 13:53 ` Jan Kiszka
2009-06-14 11:13 ` Avi Kivity
2009-06-14 11:25 ` Jan Kiszka
2009-06-14 11:31 ` Avi Kivity
2009-06-14 12:47 ` Jan Kiszka
2009-06-14 12:58 ` Avi Kivity [this message]
2009-06-14 13:06 ` Jan Kiszka
2009-06-14 13:14 ` Avi Kivity
2009-06-23 0:41 ` Dustin Kirkland
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=4A34F3FF.7040605@redhat.com \
--to=avi@redhat.com \
--cc=eak@us.ibm.com \
--cc=glommer@redhat.com \
--cc=jan.kiszka@web.de \
--cc=kvm@vger.kernel.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).