From mboxrd@z Thu Jan 1 00:00:00 1970 From: Avi Kivity Subject: Re: [PATCH 3/3] vfio: Enable vfio-pci and mark supported Date: Tue, 14 Aug 2012 17:35:46 +0300 Message-ID: <502A6242.8010708@redhat.com> References: <20120801050241.22163.78549.stgit@bling.home> <20120801051821.22163.64385.stgit@bling.home> <5018D78A.4040704@web.de> <87sjbq8mfd.fsf@codemonkey.ws> <1344922050.4683.231.camel@ul30vt.home> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: aik@ozlabs.ru, Anthony Liguori , Jan Kiszka , qemu-devel@nongnu.org, kvm@vger.kernel.org To: Alex Williamson Return-path: In-Reply-To: <1344922050.4683.231.camel@ul30vt.home> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: qemu-devel-bounces+gceq-qemu-devel=gmane.org@nongnu.org Sender: qemu-devel-bounces+gceq-qemu-devel=gmane.org@nongnu.org List-Id: kvm.vger.kernel.org On 08/14/2012 08:27 AM, Alex Williamson wrote: >> > >> > Do we need this level of control? Open question I'm just wondering every >> > time a new feature gets added together with --disable/--enable >> > switches. >> >> I don't think so--it's easy enough for an administrator to disable vfio >> for a user. > > Ok, out voted. I'll remove. Thanks, > There is an advantage to --enable-blah in that it errors out if build requirements are not satisfied, compared to silently disabling the feature with a plain ./configure. This is important for distro builds which can start to silently break features when we add a new build requirement. But it can be done later, possibly with a new --enable=vfio,kvm,... list instead of individual features. -- error compiling committee.c: too many arguments to function