From: Arnaldo Carvalho de Melo <acme@kernel.org>
To: Ian Rogers <irogers@google.com>
Cc: Aditya Gupta <adityag@linux.ibm.com>,
jolsa@kernel.org, namhyung@kernel.org,
linux-perf-users@vger.kernel.org, linuxppc-dev@lists.ozlabs.org,
maddy@linux.ibm.com, atrajeev@linux.vnet.ibm.com,
kjain@linux.ibm.com, disgoel@linux.vnet.ibm.com,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH 1/1] perf tests task_analyzer: Check perf build options for libtraceevent support
Date: Fri, 28 Jul 2023 15:30:02 -0300 [thread overview]
Message-ID: <ZMQJKmV3XtwtZJtO@kernel.org> (raw)
In-Reply-To: <CAP-5=fW1zkpJ4zr4ngz=6bZQuE6hOHo4AtXwUsVJK9oiDSc_mg@mail.gmail.com>
Em Fri, Jul 28, 2023 at 09:01:11AM -0700, Ian Rogers escreveu:
> On Fri, Jul 28, 2023 at 7:54 AM Arnaldo Carvalho de Melo
> <acme@kernel.org> wrote:
> >
> > Em Tue, Jul 25, 2023 at 11:46:49AM +0530, Aditya Gupta escreveu:
> > > Currently we depend on output of 'perf record -e "sched:sched_switch"', to
> > > check whether perf was built with libtraceevent support.
> > >
> > > Instead, a more straightforward approach can be to check the build options,
> > > using 'perf version --build-options', to check for libtraceevent support.
> > >
> > > When perf is compiled WITHOUT libtraceevent ('make NO_LIBTRACEEVENT=1'),
> > > 'perf version --build-options' outputs (output trimmed):
> > >
> > > ...
> > > libtraceevent: [ OFF ] # HAVE_LIBTRACEEVENT
> > > ...
> > >
> > > While, when perf is compiled WITH libtraceevent,
> > >
> > > 'perf version --build-options' outputs:
> > >
> > > ...
> > > libtraceevent: [ on ] # HAVE_LIBTRACEEVENT
> > > ...
> > >
> > > Suggested-by: Ian Rogers <irogers@google.com>
> > > Signed-off-by: Aditya Gupta <adityag@linux.ibm.com>
> > > ---
> > >
> > > tools/perf/tests/shell/test_task_analyzer.sh | 2 +-
> > > 1 file changed, 1 insertion(+), 1 deletion(-)
> > >
> > > diff --git a/tools/perf/tests/shell/test_task_analyzer.sh b/tools/perf/tests/shell/test_task_analyzer.sh
> > > index 0095abbe20ca..a28d784987b4 100755
> > > --- a/tools/perf/tests/shell/test_task_analyzer.sh
> > > +++ b/tools/perf/tests/shell/test_task_analyzer.sh
> > > @@ -52,7 +52,7 @@ find_str_or_fail() {
> > >
> > > # check if perf is compiled with libtraceevent support
> > > skip_no_probe_record_support() {
> > > - perf record -e "sched:sched_switch" -a -- sleep 1 2>&1 | grep "libtraceevent is necessary for tracepoint support" && return 2
> > > + perf version --build-options | grep HAVE_LIBTRACEEVENT | grep -q OFF && return 2
> > > return 0
> >
> > I'll apply this, but please consider adding a:
> >
> > perf build --has libtraceevent
>
> That's a nice idea. You mean add a script like perf-archive.sh?
Nope, I would just add a new builtin-build.c (or some other more
suitable name to query what was built into perf) and then it would just
do a simple search on the same array that 'perf version --build-options'
currently uses (or the array that it would then share with 'perf
build', I haven't looked at the source code.).
So instead of a series of fork + execs we would just have one.
- Arnaldo
> Perhaps this flag should be supported by perf version instead.
>
> Thanks,
> Ian
>
> > subcommand to have that query made more compact and to avoid the two
> > extra grep.
> >
> > BTW, I'll change that to:
> >
> > [acme@quaco perf-tools-next]$ perf version --build-options | grep " on .* HAVE_LIBTRACEEVENT"
> > libtraceevent: [ on ] # HAVE_LIBTRACEEVENT
> > [acme@quaco perf-tools-next]$
> >
> > replacing "on" with OFF, so that we have just one grep.
> >
> > Thanks,
> >
> > - Arnaldo
> >
> > > }
> > >
> > > --
> > > 2.41.0
> > >
> >
> > --
> >
> > - Arnaldo
--
- Arnaldo
next prev parent reply other threads:[~2023-07-28 18:31 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-07-25 6:16 [PATCH 1/1] perf tests task_analyzer: Check perf build options for libtraceevent support Aditya Gupta
2023-07-28 14:54 ` Arnaldo Carvalho de Melo
2023-07-28 16:01 ` Ian Rogers
2023-07-28 18:30 ` Arnaldo Carvalho de Melo [this message]
2023-08-03 3:03 ` Aditya Gupta
2023-08-03 7:22 ` Athira Rajeev
2023-08-07 5:40 ` Aditya Gupta
2023-07-29 7:39 ` Aditya Gupta
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=ZMQJKmV3XtwtZJtO@kernel.org \
--to=acme@kernel.org \
--cc=adityag@linux.ibm.com \
--cc=atrajeev@linux.vnet.ibm.com \
--cc=disgoel@linux.vnet.ibm.com \
--cc=irogers@google.com \
--cc=jolsa@kernel.org \
--cc=kjain@linux.ibm.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-perf-users@vger.kernel.org \
--cc=linuxppc-dev@lists.ozlabs.org \
--cc=maddy@linux.ibm.com \
--cc=namhyung@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).