From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from eggs.gnu.org ([208.118.235.92]:56651)
	by lists.gnu.org with esmtp (Exim 4.71)
	(envelope-from <avi@redhat.com>) id 1T1IDv-0005Ux-VX
	for qemu-devel@nongnu.org; Tue, 14 Aug 2012 10:36:03 -0400
Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)
	(envelope-from <avi@redhat.com>) id 1T1IDp-0002bm-Uq
	for qemu-devel@nongnu.org; Tue, 14 Aug 2012 10:35:59 -0400
Received: from mx1.redhat.com ([209.132.183.28]:31605)
	by eggs.gnu.org with esmtp (Exim 4.71)
	(envelope-from <avi@redhat.com>) id 1T1IDp-0002YE-NG
	for qemu-devel@nongnu.org; Tue, 14 Aug 2012 10:35:53 -0400
Message-ID: <502A6242.8010708@redhat.com>
Date: Tue, 14 Aug 2012 17:35:46 +0300
From: Avi Kivity <avi@redhat.com>
MIME-Version: 1.0
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>
In-Reply-To: <1344922050.4683.231.camel@ul30vt.home>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
Subject: Re: [Qemu-devel] [PATCH 3/3] vfio: Enable vfio-pci and mark
	supported
List-Id: <qemu-devel.nongnu.org>
List-Unsubscribe: <https://lists.nongnu.org/mailman/options/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=unsubscribe>
List-Archive: <http://lists.nongnu.org/archive/html/qemu-devel>
List-Post: <mailto:qemu-devel@nongnu.org>
List-Help: <mailto:qemu-devel-request@nongnu.org?subject=help>
List-Subscribe: <https://lists.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=subscribe>
To: Alex Williamson <alex.williamson@redhat.com>
Cc: aik@ozlabs.ru, Anthony Liguori <aliguori@us.ibm.com>, Jan Kiszka <jan.kiszka@web.de>, qemu-devel@nongnu.org, 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