From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mga03.intel.com (mga03.intel.com [134.134.136.65]) by dpdk.org (Postfix) with ESMTP id E76325A31 for ; Tue, 21 Apr 2015 11:35:45 +0200 (CEST) Received: from fmsmga003.fm.intel.com ([10.253.24.29]) by orsmga103.jf.intel.com with ESMTP; 21 Apr 2015 02:35:46 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.11,614,1422950400"; d="scan'208";a="483607595" Received: from irsmsx152.ger.corp.intel.com ([163.33.192.66]) by FMSMGA003.fm.intel.com with ESMTP; 21 Apr 2015 02:35:44 -0700 Received: from irsmsx109.ger.corp.intel.com ([169.254.13.95]) by IRSMSX152.ger.corp.intel.com ([169.254.6.7]) with mapi id 14.03.0224.002; Tue, 21 Apr 2015 10:34:28 +0100 From: "Burakov, Anatoly" To: Stephen Hemminger , "dev@dpdk.org" Thread-Topic: [dpdk-dev] [PATCH] vfio: don't silently drop VFIO support Thread-Index: AQHQe5iKlnF3SJ8U8Uu+6UqyJsRwB51XNKrw Date: Tue, 21 Apr 2015 09:34:27 +0000 Message-ID: References: <1429554771-32365-1-git-send-email-stephen@networkplumber.org> In-Reply-To: <1429554771-32365-1-git-send-email-stephen@networkplumber.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [163.33.239.182] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [dpdk-dev] [PATCH] vfio: don't silently drop VFIO support X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: patches and discussions about DPDK List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Apr 2015 09:35:46 -0000 Hi Stephen, > The VFIO_PRESENT #define was a landmine and we hit it. > The DPDK has a config system and it should be used rather than silently > dropping a feature during build only to have it fail at run time. >=20 > If VFIO is configured, and the kernel headers are not present the build > should fail. Rather than leaving developers puzzling why the build system > (with old kernel headers) produced non functioning DPDK and their system > (with new kernel headers) produced correctly working DPDK. >=20 > As a matter of policy, really no code should be looking at > except for kernel drivers with compat files. In theory, I agree with you. In practice however, this change will uncondit= ionally break builds on pre-VFIO kernels (<3.6). This may be OK now, but wa= sn't OK at the time it was developed because pre-VFIO kernels were still ve= ry much prevalent. AFAIK, VFIO is enabled by default, so maybe we should di= sable it in the default configs? Thanks, Anatoly