Re: qemu-kvm broken after ./configure --disable-kvm

[Avi Kivity <avi@redhat.com>]

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