From: Steven Rostedt <rostedt@goodmis.org>
To: Christoph Hellwig <hch@infradead.org>
Cc: Vincent Whitchurch <vincent.whitchurch@axis.com>,
Ingo Molnar <mingo@redhat.com>,
kernel@axis.com, linux-kernel@vger.kernel.org
Subject: Re: [PATCH] tracing: Export tracing_start() and tracing_stop()
Date: Mon, 7 Jun 2021 09:14:32 -0400 [thread overview]
Message-ID: <20210607091432.667ff0ba@oasis.local.home> (raw)
In-Reply-To: <YL3X7yRr1+yW/PHU@infradead.org>
On Mon, 7 Jun 2021 09:25:19 +0100
Christoph Hellwig <hch@infradead.org> wrote:
> On Wed, Jun 02, 2021 at 10:01:18AM +0200, Vincent Whitchurch wrote:
> > tracing_stop() is very useful during hands-on debugging for getting the
> > trace to stop exactly when the problem is detected. Export this to
> > modules.
> >
> > Personally, I haven't yet found the need to use tracing_start() from
> > code since I usually start tracing via tracefs, but export that too for
> > symmetry since it may have its uses together with tracing_stop().
>
> NAK, no exports for unused symbols.
Normally I would NAK this NAK because this is not normal functionality
that modules could use. It's for debugging, similar to trace_printk(),
and there should be no used symbols in any modules. This is something
for debugging purposes only and should never be in shipped kernels.
That said though, tracing_stop() is probably not what is wanted
(unless its for a suspend to ram thing). According to the above
description, the author really wants to use "tracing_off()" and not
"tracing_stop()" as tracing_off() is faster and can be turned back on
in user-space with the "tracing_on" file in tracefs, where as,
tracing_stop() can not be. tracing_stop() needs a tracing_start() to
get it going again.
And tracing_off() is already EXPORT_SYMBOL_GPL() (as it is commonly
used for debugging of modules). Again, it shouldn't have any in-kernel
users in modules, because, like I stated above, it's similar to
trace_printk() which should be removed before pushing to Linus.
I'll NAK this patch for a different reason. Use tracing_off() instead.
-- Steve
next prev parent reply other threads:[~2021-06-07 13:14 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-06-02 8:01 [PATCH] tracing: Export tracing_start() and tracing_stop() Vincent Whitchurch
2021-06-07 8:25 ` Christoph Hellwig
2021-06-07 13:14 ` Steven Rostedt [this message]
2021-06-08 12:59 ` Vincent Whitchurch
2021-06-08 13:24 ` Steven Rostedt
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20210607091432.667ff0ba@oasis.local.home \
--to=rostedt@goodmis.org \
--cc=hch@infradead.org \
--cc=kernel@axis.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@redhat.com \
--cc=vincent.whitchurch@axis.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.