From mboxrd@z Thu Jan 1 00:00:00 1970 From: Stephen Hemminger Subject: Re: [PATCH] vfio: don't silently drop VFIO support Date: Tue, 21 Apr 2015 10:34:59 -0700 Message-ID: <20150421103459.6b8094d0@urahara> References: <1429554771-32365-1-git-send-email-stephen@networkplumber.org> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: "dev-VfR2kkLFssw@public.gmane.org" To: "Burakov, Anatoly" Return-path: In-Reply-To: List-Id: patches and discussions about DPDK List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces-VfR2kkLFssw@public.gmane.org Sender: "dev" On Tue, 21 Apr 2015 09:34:27 +0000 "Burakov, Anatoly" 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 > > 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.