From mboxrd@z Thu Jan 1 00:00:00 1970 From: Avi Kivity Subject: Re: Q: status of kvm/ subdir in qemu-kvm tarball? Date: Sun, 27 Feb 2011 18:28:49 +0200 Message-ID: <4D6A7BC1.9020703@redhat.com> References: <4D64E9C6.8000505@msgid.tls.msk.ru> <4D64F008.7050308@siemens.com> <4D64F2C0.4000609@msgid.tls.msk.ru> <4D650479.30609@siemens.com> <4D650884.3090801@msgid.tls.msk.ru> <4D650F85.10502@siemens.com> <4D651A1D.8030206@msgid.tls.msk.ru> <4D652040.9000309@siemens.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Michael Tokarev , KVM list To: Jan Kiszka Return-path: Received: from mx1.redhat.com ([209.132.183.28]:30279 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752166Ab1B0Q3A (ORCPT ); Sun, 27 Feb 2011 11:29:00 -0500 In-Reply-To: <4D652040.9000309@siemens.com> Sender: kvm-owner@vger.kernel.org List-ID: 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. > - 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? If everyone did that we'd be in a mess of duplication. I'd like not to contribute to that. -- error compiling committee.c: too many arguments to function