From: Steven Rostedt <rostedt@goodmis.org>
To: Masami Hiramatsu <mhiramat@kernel.org>
Cc: Tom Zanussi <zanussi@kernel.org>,
skhan@linuxfoundation.org, linux-kernel@vger.kernel.org,
linux-rt-users@vger.kernel.org
Subject: Re: [PATCH v2 2/2] selftests/ftrace: Distinguish between hist and synthetic event checks
Date: Fri, 29 May 2020 10:53:21 -0400 [thread overview]
Message-ID: <20200529105321.0bcf3219@oasis.local.home> (raw)
In-Reply-To: <20200529233845.25d975c6b23d62da1dfb75cb@kernel.org>
On Fri, 29 May 2020 23:38:45 +0900
Masami Hiramatsu <mhiramat@kernel.org> wrote:
> Hi Tom,
>
> On Thu, 28 May 2020 14:32:38 -0500
> Tom Zanussi <zanussi@kernel.org> wrote:
>
> > With synthetic events now a separate config item as a result of
> > 'tracing: Move synthetic events to a separate file', tests that use
> > both need to explicitly check for hist trigger support rather than
> > relying on hist triggers to pull in synthetic events.
> >
> > Add an additional hist trigger check to all the trigger tests that now
> > require it, otherwise they'll fail if synthetic events but not hist
> > triggers are enabled.
>
> OK, this looks good to me. And if you don't want to repeat it,
> you can also put the check function into the test.d/functions.
>
> Acked-by: Masami Hiramatsu <mhiramat@kernel.org>
Thanks Tom and Masami. I'm running tests on these now.
-- Steve
prev parent reply other threads:[~2020-05-29 14:53 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-05-28 19:32 [PATCH v2 0/2] tracing: Make synthetic events a separate option Tom Zanussi
2020-05-28 19:32 ` [PATCH v2 1/2] tracing: Move synthetic events to a separate file Tom Zanussi
2020-05-28 19:32 ` [PATCH v2 2/2] selftests/ftrace: Distinguish between hist and synthetic event checks Tom Zanussi
2020-05-29 14:38 ` Masami Hiramatsu
2020-05-29 14:53 ` Steven Rostedt [this message]
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=20200529105321.0bcf3219@oasis.local.home \
--to=rostedt@goodmis.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-rt-users@vger.kernel.org \
--cc=mhiramat@kernel.org \
--cc=skhan@linuxfoundation.org \
--cc=zanussi@kernel.org \
/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.