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. >>>> >>> 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. 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...). > >> 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. > Maybe a good topic for next Tuesday. Jan
Attachment:
signature.asc
Description: OpenPGP digital signature
