Received: by 2002:a05:6a10:22f:0:0:0:0 with SMTP id 15csp536749pxk; Thu, 24 Sep 2020 11:33:50 -0700 (PDT) X-Google-Smtp-Source: ABdhPJxGqNkRLi+OP3hfdTRTbXWNopLejp3+vxaSHDW//jz6yweIEY8hV9bKJS+pV9ogKqJtx/pD X-Received: by 2002:aa7:ca4f:: with SMTP id j15mr105518edt.233.1600972430742; Thu, 24 Sep 2020 11:33:50 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1600972430; cv=none; d=google.com; s=arc-20160816; b=O4MWYXofKFUuK4Yp2IJfGC01DKO5cu+EDtrOkMTdRYLZ9DxQAnShbHu6dmNvARbTpX ytfhuBn3D9BJLgxxwM163jLHstZczG2jSkJqFJOXMV7Cf0jmDp2SQDDRnf72VkzAiYWP 0xm3NRu5lGhv0MLqlgufVbWwdBa/NCTSjbGxML2fBD95HH+rUfMLlbcQ147jCk+2l89/ F9M/lbd8VUPf2o70yKSIW8/KJfgSgDfUYKd5DpHwTD+A7oSRKEQfsTOQGeuinYyphvYR fr/ssI8FCGnjn7U41xfmy/zcSvqe+wmRNN4PNC3E3LUQ8w488Y4rggkHlgCzTj2d/l1S 4/Tg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:mime-version :references:in-reply-to:message-id:subject:cc:to:from:date; bh=pjWCWewo14to1A2PTrRk4+gf7HPZ9Utu8thwB30fdWI=; b=Jn/UBSaxlAwcjEpODlsjXUk+eEO9ZNunLKIc2kGLgpAZTzKXumSyo2xBta78b3Fvbe D6mnhaDWP0ZkSjT5e9Sx/ph1FdhlR6hF5gMerRn2I2QAV27O4Zh2Za2N0GTxRh257DS3 tzArqxO1XDOWM7zy/U01e1sE68QSDMMX38hgVCujKFfWmoQ7nv9Lt3kCX8nxL+onHeIc SlhvSzSvZvwy8HIdF9Pzg8uHRa6liuFSJpuRngenCigJBanJnkIIxhf1gq0d86YKfQer C9Zfj7IEFAyXSsNDrneyRqMh5KcQV04JtfTY2KKM2Fb8jWijGGrjYZpcfTfhFe/jms+e uA3w== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id h10si137837edr.206.2020.09.24.11.33.27; Thu, 24 Sep 2020 11:33:50 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1728703AbgIXSaa (ORCPT + 99 others); Thu, 24 Sep 2020 14:30:30 -0400 Received: from mail.kernel.org ([198.145.29.99]:46538 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1728264AbgIXSa3 (ORCPT ); Thu, 24 Sep 2020 14:30:29 -0400 Received: from gandalf.local.home (cpe-66-24-58-225.stny.res.rr.com [66.24.58.225]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id BBCB42311E; Thu, 24 Sep 2020 18:30:27 +0000 (UTC) Date: Thu, 24 Sep 2020 14:30:25 -0400 From: Steven Rostedt To: Mathieu Desnoyers Cc: linux-kernel , Yafang Shao , Axel Rasmussen , Andrew Morton , Vlastimil Babka , Michel Lespinasse , Daniel Jordan , Davidlohr Bueso , linux-mm , Ingo Molnar , Joonsoo Kim Subject: Re: [PATCH 1/2] tracepoints: Add helper to test if tracepoint is enabled in a header Message-ID: <20200924143025.58dc3c1f@gandalf.local.home> In-Reply-To: <2006335081.68212.1600969345189.JavaMail.zimbra@efficios.com> References: <20200924170928.466191266@goodmis.org> <20200924171846.993048030@goodmis.org> <2006335081.68212.1600969345189.JavaMail.zimbra@efficios.com> X-Mailer: Claws Mail 3.17.3 (GTK+ 2.24.32; x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, 24 Sep 2020 13:42:25 -0400 (EDT) Mathieu Desnoyers wrote: > > Signed-off-by: Steven Rostedt (VMware) > > --- > > Documentation/trace/tracepoints.rst | 25 ++++++++++++++++++++++ > > include/linux/tracepoint-defs.h | 33 +++++++++++++++++++++++++++++ > > 2 files changed, 58 insertions(+) > > > > diff --git a/Documentation/trace/tracepoints.rst > > b/Documentation/trace/tracepoints.rst > > index 6e3ce3bf3593..833d39ee1c44 100644 > > --- a/Documentation/trace/tracepoints.rst > > +++ b/Documentation/trace/tracepoints.rst > > @@ -146,3 +146,28 @@ with jump labels and avoid conditional branches. > > define tracepoints. Check http://lwn.net/Articles/379903, > > http://lwn.net/Articles/381064 and http://lwn.net/Articles/383362 > > for a series of articles with more details. > > + > > +If you require calling a tracepoint from a header file, it is not > > +recommended to call one directly or to use the trace__enabled() > > +function call, as tracepoints in header files can have side effects if a > > +header is included from a file that has CREATE_TRACE_POINTS set. Instead, > > +include tracepoint-defs.h and use trace_enabled(). > > Tracepoints per-se have no issues being used from header files. The TRACE_EVENT > infrastructure seems to be the cause of this problem. We should fix trace events > rather than require all users to use weird work-arounds thorough the kernel code > base. That's like saying "let's solve include hell". Note, in the past there has also been issues with the headers included also having issues including other headers and cause a dependency loop. But the magic of trace events (for both perf and ftrace, sorry if you refused to use it), is that people who add tracepoints do not need to know how tracepoints work. There's no adding of registering of them, or anything else. The formats and everything they record appear in the tracefs file system. How are your trace events created? All manual, or do you have helper macros. Would these be safe if a bunch were included? > > I am not against the idea of a tracepoint_enabled(tp), but I am against the > motivation behind this patch and the new tracepoint user requirements it documents. It removes the open coded code that has been in the kernel for the last 4 years. > > > + > > +In a C file:: > > + > > + void do_trace_foo_bar_wrapper(args) > > + { > > + trace_foo_bar(args); > > + } > > + > > +In the header file:: > > + > > + DECLEARE_TRACEPOINT(foo_bar); > > + > > + static inline void some_inline_function() > > + { > > + [..] > > + if (trace_enabled(foo_bar)) > > Is it trace_enabled() or tracepoint_enabled() ? There is a mismatch > between the commit message/code and the documentation. Yes, it should be tracepoint_enabled(). Thanks for catching that. Anyway, this shouldn't affect you in any way, as it's just adding wrappers around locations that have been doing this for years. If you want, I can change the name to trace_event_enabled() and put the code in trace_events-defs.h instead. Which would simply include tracepoints-defs.h and have the exact same code. -- Steve