On 08/01/2019 11:24, Alex Williamson wrote:
> On Tue, 8 Jan 2019 10:52:43 +1100
> Alexey Kardashevskiy <aik@xxxxxxxxx> wrote:
>
>> On 08/01/2019 07:13, Alex Williamson wrote:
>>> On Mon, 7 Jan 2019 20:39:19 +0900
>>> Masahiro Yamada <yamada.masahiro@xxxxxxxxxxxxx> wrote:
>>>
>>>> On Mon, Jan 7, 2019 at 8:09 PM Cornelia Huck <cohuck@xxxxxxxxxx> wrote:
>>>>>
>>>>> On Mon, 7 Jan 2019 19:12:10 +0900
>>>>> Masahiro Yamada <yamada.masahiro@xxxxxxxxxxxxx> wrote:
>>>>>
>>>>>> On Mon, Jan 7, 2019 at 6:18 PM Michael Ellerman <mpe@xxxxxxxxxxxxxx> wrote:
>>>>>>>
>>>>>>> Laura Abbott <labbott@xxxxxxxxxx> 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 <labbott@xxxxxxxxxx>
>>>>>
>>>>> (...)
>>>>>
>>>>>>> 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,
I suggest making in-tree and out-of-tree behavior equal - both either
fail or compile. Just makes sense to me.
Since out-of-tree adds extra -I, then there should have been a reason
for that at the time (before 2005 though). Unfortunately git blame does
not say why it was done this way for out-of-tree so imho the safest
thing is to add -I for in-tree as well. Or ditch extra -I and do 2) or
3) - this is fine too and can count as an impressive compile
optimization, although... look below :)
> or are you suggesting to fix the in-tree build behavior to
> be as inefficient as the out-of-tree behavior in general?
Inefficient you say. Hm.
I tried this:
--- scripts/Makefile.lib.old 2019-01-08 11:39:51.830983393 +1100
+++ scripts/Makefile.lib 2019-01-08 13:09:54.199054981 +1100
@@ -140,11 +140,6 @@
# If building the kernel in a separate objtree expand all occurrences
# of -Idir to -I$(srctree)/dir except for absolute paths (starting with
'/').
-ifeq ($(KBUILD_SRC),)
-__c_flags = $(_c_flags)
-__a_flags = $(_a_flags)
-__cpp_flags = $(_cpp_flags)
-else
# -I$(obj) locates generated .h files
# $(call addtree,-I$(obj)) locates .h files in srctree, from generated
.c files
@@ -154,7 +149,6 @@
$(call flags,_c_flags)
__a_flags = $(call flags,_a_flags)
__cpp_flags = $(call flags,_cpp_flags)
-endif
Compiled 3 times with the patch and without, "make clean ; time make
-j200 vmlinux modules".
No patch:
real 4m33.047s user 481m48.322s sys 10m15.639s
real 4m29.038s user 480m22.873s sys 10m11.394s
real 4m34.373s user 483m7.570s sys 10m10.559s
With the patch:
real 4m32.008s user 479m54.207s sys 10m13.075s
real 4m30.027s user 479m46.272s sys 10m15.886s
real 4m31.548s user 480m2.897s sys 10m10.024
which is slightly faster but I guess within accuracy.
> 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,
--
Alexey
