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:
signature.asc
Description: OpenPGP digital signature