From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from [140.186.70.92] (port=49862 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1PZnnF-0008QF-MO for qemu-devel@nongnu.org; Mon, 03 Jan 2011 12:02:03 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1PZnnE-0007Bt-DO for qemu-devel@nongnu.org; Mon, 03 Jan 2011 12:02:01 -0500 Received: from mx1.redhat.com ([209.132.183.28]:32736) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1PZnnE-0007Bo-2a for qemu-devel@nongnu.org; Mon, 03 Jan 2011 12:02:00 -0500 Message-ID: <4D220103.5070707@redhat.com> Date: Mon, 03 Jan 2011 19:01:55 +0200 From: Avi Kivity MIME-Version: 1.0 References: <4ffa4f23bc93aa5af90d836986771bb6d9856bf9.1294043582.git.jan.kiszka@web.de> <4D21F464.1070807@redhat.com> <4D21FF48.70103@web.de> In-Reply-To: <4D21FF48.70103@web.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [Qemu-devel] Re: [PATCH v2 17/17] kvm: Drop dependencies on very old capabilities List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Jan Kiszka Cc: Jan Kiszka , Marcelo Tosatti , qemu-devel@nongnu.org, kvm@vger.kernel.org On 01/03/2011 06:54 PM, Jan Kiszka wrote: > Am 03.01.2011 17:08, Avi Kivity wrote: > > On 01/03/2011 10:33 AM, Jan Kiszka wrote: > >> From: Jan Kiszka > >> > >> COALESCED_MMIO, SYNC_MMU, EXT_CPUID, CLOCKSOURCE, NOP_IO_DELAY, PV_MMU - > >> all these caps predate features on which we already depend at build > >> time. Moreover, the check for KVM_CAP_EXT_CPUID is unneeded as we > >> already test& fail is a more recent feature is missing. > > > > No. Each test documents a dependency of qemu on a kvm feature. Even > > though something like SYNC_MMU is unlikely to go away, as long as we > > depend on it, we require the feature. > > > > Then at least move all those KVM_CAPs we need at build time into > configure. Need a run time check as well (build on new kernel, run on old kernel, or run on even newer kernel that lost a feature). > I really see no value in keeping ugly conditional code > around, A) because those paths won't be tested and B) none of the CAPs > touched here are to pass away without a replacement that will require > user space adaption anyway. I'm fine with a series of checks during init time with no fallback. I'm not fine with just dropping those away. Reducing code size is great, but not at the cost of undiagnosed runtime failures. -- error compiling committee.c: too many arguments to function