Received: by 2002:ad5:474a:0:0:0:0:0 with SMTP id i10csp4140930imu; Mon, 7 Jan 2019 16:37:29 -0800 (PST) X-Google-Smtp-Source: ALg8bN5vb3aS09SdyEpRi6eEUhPBcMoE/SuqAqI2ZRGDt7o7hsPDnwHR76i50E4PQtGUYZ0CBOMH X-Received: by 2002:a63:5723:: with SMTP id l35mr30699577pgb.228.1546907849626; Mon, 07 Jan 2019 16:37:29 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1546907849; cv=none; d=google.com; s=arc-20160816; b=LEB++gA8EzDVyZ3LN/PWJmaELy/D8xmmLIW+RT1WfnV466DCQTJz7O/JDD+yz04pH9 WA7YLpJfgI6g6TD+ChZFoC1SLunCRDVJDjfk3Ls1qP8sVp6Hu2ZCUoGvkGCRTH89JtVq WBKHcKzU5yQ+NNKzXAkTxYUkYlzItrqvdZSmMu4ELzZuiVvi3VPIRpxIK7fc0xv8qRP0 xbFOeMbQfBaKDw+UvrI466wXS7HzEonuO1rI32TU0tU2nfSl6QHeoXs82Gu9AgWpqecX zWz1ohMDd0seXd+k6ehZkabEPb8xDDb+UxoZbr00dLBy7UUqzFzu3fR7OnYDRD9O9nXL pqPA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding:mime-version :organization:references:in-reply-to:message-id:subject:cc:to:from :date; bh=iP9OZ0ulhbvC/OWIfD3O3mETFKS1J77O+nBFx/oOqZk=; b=xHRffZiFPq1+3oIBOzgL1FpXEMBCNrjkGbrjJipjdjNQ4ddNDcLSzfaG7TquGgb2O+ 1mMNBdSAXkFQrtl+xAU/tlCMS8Gu4WhdWdCPCrG97rdpkB+DArLWtqhNuh77Du2VbVtT fGV5vpm6FMGow2Wmd+izFUTBXn4+T8GfJEonrmJoVrDb/4zxL1zCNexdev0Ycs+PZ7XM h9djqrY7+CaN7tdhL4oupiIhHEga8CwpKoVftgQDVqYTKYwzSKd5JmniUfLG+YTkPazJ Y04U6FuAZMARmh/IOATluUrpQZkKr5Kpu9Q3YfDGwpoBxF2jT3mTcUXTw0Qu6yKD0MCK 2SoA== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=redhat.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id d5si61480771pla.361.2019.01.07.16.37.12; Mon, 07 Jan 2019 16:37:29 -0800 (PST) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=redhat.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727160AbfAHAYj (ORCPT + 99 others); Mon, 7 Jan 2019 19:24:39 -0500 Received: from mx1.redhat.com ([209.132.183.28]:59076 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726667AbfAHAYj (ORCPT ); Mon, 7 Jan 2019 19:24:39 -0500 Received: from smtp.corp.redhat.com (int-mx02.intmail.prod.int.phx2.redhat.com [10.5.11.12]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id DF99889AE4; Tue, 8 Jan 2019 00:24:38 +0000 (UTC) Received: from x1.home (ovpn-116-25.phx2.redhat.com [10.3.116.25]) by smtp.corp.redhat.com (Postfix) with ESMTP id 4952260CD0; Tue, 8 Jan 2019 00:24:38 +0000 (UTC) Date: Mon, 7 Jan 2019 17:24:37 -0700 From: Alex Williamson To: Alexey Kardashevskiy Cc: Masahiro Yamada , Cornelia Huck , Michael Ellerman , Laura Abbott , kvm@vger.kernel.org, Linux Kernel Mailing List Subject: Re: [PATCH] vfio_pci: Add local source directory as include Message-ID: <20190107172437.0f0b5331@x1.home> In-Reply-To: <4b9b6cf2-d39e-8dd2-9271-158489b03a61@ozlabs.ru> References: <20190104195714.30045-1-labbott@redhat.com> <874lakc09x.fsf@concordia.ellerman.id.au> <20190107120716.51d95854.cohuck@redhat.com> <20190107131341.00581863@x1.home> <4b9b6cf2-d39e-8dd2-9271-158489b03a61@ozlabs.ru> Organization: Red Hat MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.79 on 10.5.11.12 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.26]); Tue, 08 Jan 2019 00:24:38 +0000 (UTC) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, 8 Jan 2019 10:52:43 +1100 Alexey Kardashevskiy wrote: > On 08/01/2019 07:13, Alex Williamson wrote: > > On Mon, 7 Jan 2019 20:39:19 +0900 > > Masahiro Yamada wrote: > > > >> On Mon, Jan 7, 2019 at 8:09 PM Cornelia Huck wrote: > >>> > >>> On Mon, 7 Jan 2019 19:12:10 +0900 > >>> Masahiro Yamada wrote: > >>> > >>>> On Mon, Jan 7, 2019 at 6:18 PM Michael Ellerman wrote: > >>>>> > >>>>> Laura Abbott writes: > >>>>>> Commit 7f92891778df ("vfio_pci: Add NVIDIA GV100GL [Tesla V100 SXM2] > >>>>>> subdriver") introduced a trace.h file in the local directory but > >>>>>> missed adding the local include path, resulting in compilation > >>>>>> failures with tracepoints: > >>>>>> > >>>>>> In file included from drivers/vfio/pci/trace.h:102, > >>>>>> from drivers/vfio/pci/vfio_pci_nvlink2.c:29: > >>>>>> ./include/trace/define_trace.h:89:42: fatal error: ./trace.h: No such file or directory > >>>>>> #include TRACE_INCLUDE(TRACE_INCLUDE_FILE) > >>>>>> > >>>>>> Fix this by adjusting the include path. > >>>>>> > >>>>>> Fixes: 7f92891778df ("vfio_pci: Add NVIDIA GV100GL [Tesla V100 SXM2] subdriver") > >>>>>> Signed-off-by: Laura Abbott > >>> > >>> (...) > >>> > >>>>> Alex I assume you'll merge this fix via the vfio tree? > >>>>> > >>>>> cheers > >>>>> > >>>>>> diff --git a/drivers/vfio/pci/Makefile b/drivers/vfio/pci/Makefile > >>>>>> index 9662c063a6b1..08d4676a8495 100644 > >>>>>> --- a/drivers/vfio/pci/Makefile > >>>>>> +++ b/drivers/vfio/pci/Makefile > >>>>>> @@ -1,3 +1,4 @@ > >>>>>> +ccflags-y += -I$(src) > >>>>>> > >>>>>> vfio-pci-y := vfio_pci.o vfio_pci_intrs.o vfio_pci_rdwr.o vfio_pci_config.o > >>>>>> vfio-pci-$(CONFIG_VFIO_PCI_IGD) += vfio_pci_igd.o > >>>>>> -- > >>>>>> 2.20.1 > >>>> > >>>> > >>>> Hi. > >>>> > >>>> If I correctly understand the usage of TRACE_INCLUDE_PATH, > >>>> the correct fix should be like follows: > >>>> > >>>> > >>>> diff --git a/drivers/vfio/pci/trace.h b/drivers/vfio/pci/trace.h > >>>> index 228ccdb..4d13e51 100644 > >>>> --- a/drivers/vfio/pci/trace.h > >>>> +++ b/drivers/vfio/pci/trace.h > >>>> @@ -94,7 +94,7 @@ TRACE_EVENT(vfio_pci_npu2_mmap, > >>>> #endif /* _TRACE_VFIO_PCI_H */ > >>>> > >>>> #undef TRACE_INCLUDE_PATH > >>>> -#define TRACE_INCLUDE_PATH . > >>>> +#define TRACE_INCLUDE_PATH ../../drivers/vfio/pci > >>>> #undef TRACE_INCLUDE_FILE > >>>> #define TRACE_INCLUDE_FILE trace > >>> > >>> Going from the comments in samples/trace_events/trace-events-sample.h, > >>> I think both approaches are possible, and I see both used in various > >>> places. > >>> > >>> Personally, I'd prefer Laura's patch, as it doesn't involve hardcoding > >>> a path. > > > > Numbering options for clarity: > > > > 1) > >> ccflags-y += -I$(src) > >> would add the header search path for all files in drivers/vfio/pci/ > >> whereas only the drivers/vfio/pci/vfio_pci_nvlink2.c needs it. > >> > > > > 2) > >> CFLAGS_vfio_pci_nvlink2.o += -I$(src) > >> is a bit better. > >> However, it is not obvious why this extra header search path is needed > >> until you find vfio_pci_nvlink2.c including trace.h > >> > > > > 3) > >> #define TRACE_INCLUDE_PATH ../../drivers/vfio/pci > >> clarifies the intention because the related code is all placed in trace.h > >> > >> > >> > >> From the comment in include/trace/define_trace.h > >> TRACE_INCLUDE_PATH is relative to include/trace/define_trace.h > > > > In my scan of the tree, the most common solution seems to be 2) as this > > is essentially recommended in the sample file. 3) is well represented, > > with much fewer examples of 1), though it might depend how liberally > > we grep out or examine the use cases. Choice 1) also seems to be the > > most shotgun approach, adding to the search path for all files. > > > The shotgun approach is always used when compiling out of tree which is > what many people do anyway without realizing that there are additional > -I. Why do not we make in-tree behave the same way? Thanks, Are you suggesting bandaging this individual leaf directory, as in choice 1), because it's no worse than what happens for an out-of-tree build anyway, or are you suggesting to fix the in-tree build behavior to be as inefficient as the out-of-tree behavior in general? It appears to me that options 2) and 3) are the intended solutions for this issue while 1) is more of a workaround. Thanks, Alex > > From a > > maintenance perspective I agree that 2) seems more error prone, > > especially when the build system only catches the error on in-tree > > builds, something I rarely do. Therefore I'm leaning towards option > > 3). The hardcoded path here doesn't seem much of an issue relative to > > the negatives of the other approaches (how often do we move these > > files?) and it keeps the trace support relatively self-contained. Are > > there further arguments for or against these options? Otherwise who > > wants to formally post the TRACE_INCLUDE_PATH version? Thanks, >