On Wed, Dec 19, 2018 at 01:39:12PM -0500, Doug Ledford wrote: > On Wed, 2018-12-19 at 18:24 +0000, Weiny, Ira wrote: > > > > In addition I wrote a sample eBPF which shows how one can further > > > > filter at the tracepoints to distill the information being traced. I > > > > don't know if this should be submitted through another tree or if it > > > > is ok to take though linux-rdma? > > > > > > I think it needs to go through the tracing subsystem tree, maintained by Ingo > > > Molnar and Steven Rostedt. In addition, you need a MAINTAINERS file > > > update to go along with this. The include/trace/events/ib*mad.h files should > > > be under the INFINIBAND subsystem to patches to them get Cc:ed here. > > > Same for the samples/bpf/ibumad_*.c files. > > ^^^^^ > > > > I don't understand. > > > > The include/trace/events/ib*mad.h changes are the _only_ ones to the tracing subsystem. You're saying they should go under the IB subsystem. Which I where I posted them... > > No, I'm saying they should go through the tracing subsystem so they get > that level of review and exposure, but that the INFINIBAND substem > MAINTAINERS entry should get a new line indicating that our subsystem > should be included on changes to those files. It doesn't mean that the > files won't also flag as tracing files when someone runs the query on > the MAINTAINERS file, it means both the tracing maintainers and linux- > rdma will get Cc:ed on changes to these files. > > > So what should go through the tracing subsystem? > > Send the whole series through there, just add the changes to the > MAINTAINERS file I listed. It looks like the convention is to have a MAINTAINERS entry for the owning subsystem with a F: include/trace/events/.. Type thing in it. I think we should merge the patches through RDMA, but with the Ack of tracing folks.. > > > > drivers/infiniband/core/mad.c | 95 ++++++++- > > > > drivers/infiniband/core/user_mad.c | 7 + Otherwise these will might make merge conflicts.. Jason
