Re: Q: status of kvm/ subdir in qemu-kvm tarball?

[Jan Kiszka <jan.kiszka@web.de>]

[-- Attachment #1: Type: text/plain, Size: 2027 bytes --]

On 2011-02-27 17:28, Avi Kivity wrote:
> On 02/23/2011 04:57 PM, Jan Kiszka wrote:
>> >
>> >  The only situation where using kernel headers not provided
>> >  by qemu itself is when you want to build qemu for older
>> >  kernel and omit some features and runtime tests.  But this
>> >  is hardly a good goal to support.
>>
>> I don't think the goal of the #ifdefs was ever some kind of size
>> optimization but just for the sake of avoiding build breakages.
>>
> 
> Yes.
> 
>> Well, "rm -r kvm" is a rather minor thing. But the header discussion is
>> important IMO as we continue to see breakages in KVM builds (mostly qemu
>> upstream) due to missing #ifdefs. That means:
>>   - we do not test all variants (because it's impractical)
> 
> We could teach buildbot about it.

We could, but the test matrix wouldn't be simple. Think of CAPs that
depend on other CAPs. I don't think it would be worth the effort. And if
we forget to update a test after adding a CAP, the situation won't be
different from today.

> 
>>   - people use older headers
>>   - too much effort is wasted on fixing distributed problems that can be
>>     solved centrally
> 
> Yes.  But on the other hand carrying headers is the Wrong Thing, isn't
> it?

Well, there are also different views on this, see e.g.
http://kernelnewbies.org/KernelHeaders

>  If everyone did that we'd be in a mess of duplication.  I'd like
> not to contribute to that.

Not all distros keep their kernel headers sufficiently recent and/or
users forget to update them when updating the kernel (I just noticed
that vhost remained off in some builds here due to pre-historic distro
headers). As long as we continue adding or changing the kernel ABI, qemu
will face these problems.

We can't avoid a certain degree of mess, either in form of in-tree
header copies or via a continuously increasing number of #ifdefs in our
code. I'm really convinced now the former is both more user-friendly and
cleaner than the latter.

Jan


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 259 bytes --]