From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <stephen@networkplumber.org>
Received: from mail-pd0-f179.google.com (mail-pd0-f179.google.com
 [209.85.192.179]) by dpdk.org (Postfix) with ESMTP id 1B6B02E41
 for <dev@dpdk.org>; Tue, 21 Apr 2015 19:34:56 +0200 (CEST)
Received: by pdbqa5 with SMTP id qa5so247950395pdb.1
 for <dev@dpdk.org>; Tue, 21 Apr 2015 10:34:55 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20130820;
 h=x-gm-message-state:date:from:to:cc:subject:message-id:in-reply-to
 :references:mime-version:content-type:content-transfer-encoding;
 bh=RjDLgX4tOufXyJOwIJfzfd0YNZrCmziSYJWozML2Hcc=;
 b=UY5Fhzv+z0+ftVg7QUb52n7uavb2N2N+7SMOOt7rZ8T5Qi4NM0CfChLs1sjjY00dbC
 n5OQow+VFD4gZ8AgkznKVJ4FwebsGocCyjCLcR7dmtUZbnkxoOh0gyyAFG2JfR2KL9KM
 KlqC6vZMh84fdYfJ/AUAa5bi8mfUZ7/HYDmGZZVyCX2ZGdtJHyrQzumJKBhgGzPqs25G
 LYZpawg5lWp7yzQoSln8rZFDKxnyhRM5jdU8pp6yoSI6p1n5dvYGGKp7tj88y4nxwA5k
 48/VNFTVgarntAZbLM2PxiA3+GOnA8+eFSYG6PT3A/2gtWUKY+K9eBSi6jraBwRPIez7
 1dqQ==
X-Gm-Message-State: ALoCoQnS0k6AtO3rv1lvojsRbbLRegMdSF+YQD50Gj33U7oFdDchFmEO9dmKxSDYhmdZpKbbnSx2
X-Received: by 10.66.142.137 with SMTP id rw9mr39228080pab.56.1429637695536;
 Tue, 21 Apr 2015 10:34:55 -0700 (PDT)
Received: from urahara (static-50-53-82-155.bvtn.or.frontiernet.net.
 [50.53.82.155])
 by mx.google.com with ESMTPSA id ae9sm2672244pac.25.2015.04.21.10.34.55
 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);
 Tue, 21 Apr 2015 10:34:55 -0700 (PDT)
Date: Tue, 21 Apr 2015 10:34:59 -0700
From: Stephen Hemminger <stephen@networkplumber.org>
To: "Burakov, Anatoly" <anatoly.burakov@intel.com>
Message-ID: <20150421103459.6b8094d0@urahara>
In-Reply-To: <C6ECDF3AB251BE4894318F4E4512369780C828EF@IRSMSX109.ger.corp.intel.com>
References: <1429554771-32365-1-git-send-email-stephen@networkplumber.org>
 <C6ECDF3AB251BE4894318F4E4512369780C828EF@IRSMSX109.ger.corp.intel.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Cc: "dev@dpdk.org" <dev@dpdk.org>
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 <dev.dpdk.org>
List-Unsubscribe: <http://dpdk.org/ml/options/dev>,
 <mailto:dev-request@dpdk.org?subject=unsubscribe>
List-Archive: <http://dpdk.org/ml/archives/dev/>
List-Post: <mailto:dev@dpdk.org>
List-Help: <mailto:dev-request@dpdk.org?subject=help>
List-Subscribe: <http://dpdk.org/ml/listinfo/dev>,
 <mailto:dev-request@dpdk.org?subject=subscribe>
X-List-Received-Date: Tue, 21 Apr 2015 17:34:56 -0000

On Tue, 21 Apr 2015 09:34:27 +0000
"Burakov, Anatoly" <anatoly.burakov@intel.com> wrote:

> 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.
> > 
> > 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.
> > 
> > As a matter of policy, really no code should be looking at <linux/version.h>
> > except for kernel drivers with compat files.
> 
> In theory, I agree with you. In practice however, this change will unconditionally break builds on pre-VFIO kernels (<3.6).

If someone is building with an older kernel, then they should change the config.

> This may be OK now, but wasn't OK at the time it was developed because pre-VFIO kernels were still very much prevalent. AFAIK, VFIO is enabled by default, so maybe we should disable it in the default configs?

But failing at runtime is much worse.