> On Aug 24, 2020, at 5:56 PM, Jason Gunthorpe <jgg@xxxxxxxxxx> wrote: > > On Mon, Aug 24, 2020 at 02:24:40PM -0400, Chuck Lever wrote: >> >> >>> On Aug 24, 2020, at 1:42 PM, Jason Gunthorpe <jgg@xxxxxxxxxx> wrote: >>> >>> On Mon, Aug 17, 2020 at 09:53:05AM -0400, Chuck Lever wrote: >>>> Oracle has an interest in a common observability infrastructure in >>>> the RDMA core and ULPs. Introduce static tracepoints that can also >>>> be used as hooks for eBPF scripts, replacing infrastructure that >>>> is based on printk. This takes the same approach as tracepoints >>>> added recently in the RDMA CM. >>>> >>>> Change since v2: >>>> * Rebase on v5.9-rc1 >>>> >>>> Changes since RFC: >>>> * Correct spelling of example tracepoint in patch description >>>> * Newer tool chains don't care for tracepoints with the same name >>>> in different subsystems >>>> * Display ib_cm_events, not ib_events >>> >>> Doesn't compile: >>> >>> In file included from drivers/infiniband/core/cm_trace.h:414, >>> from drivers/infiniband/core/cm_trace.c:15: >>> ./include/trace/define_trace.h:95:42: fatal error: ./cm_trace.h: No such file or directory >>> 95 | #include TRACE_INCLUDE(TRACE_INCLUDE_FILE) >>> | ^ >>> compilation terminated. >> >> I am not able to reproduce this failure. >> >> gcc (GCC) 10.1.1 20200507 (Red Hat 10.1.1-1) > > Yep, using gcc 10 too > > Start from a clean tree? Always. >> What if you edit drivers/infiniband/core/cm_trace.h and >> change the definition of TRACE_INCLUDE_PATH from "." to >> "../../drivers/infiniband/core" ? > > It works > > It is because ./ is relative to include/trace/define_trace.h ? Yes. It appears that the many instances of "#define TRACE_INCLUDE_PATH ." already in the kernel are each accompanied by Makefile magic to make that work correctly. I neglected (again) to add that. But now that I've read the instructions in include/trace/define_trace.h, I prefer using a full relative path instead of "."-with-Makefile. Do I need to send a v4? -- Chuck Lever
