The Problem
===========

Currently the presence of a feature is checked with a combination of
perf version --build-options and greps, such as:

    perf version --build-options | grep " on .* HAVE_FEATURE"

Proposed solution
=================

As suggested by contributors in:
https://lore.kernel.org/linux-perf-users/ZMPWk5K63tadmDlU@kernel.org/

Introduce a subcommand "perf build --has", with which
scripts can test for presence of a feature, such as:

    perf build --has HAVE_FEATURE

The usage of "perf version --build-options | grep" has been replaced in two
tests, with "perf build --has" command

Also, to not duplicate the same feature list at multiple places, a new global
'supported_features' array has been introduced in builtin.h, so both commands
'perf build --has' and 'perf version --build-options' use the same array

'supported_features' feature is an array of 'struct feature_support', which
also has the name of the feature, macro used to test it's presence, and a
is_builtin member, which will be 0 if feature not built-in, and 1 if built-in

Architectures Tested
====================
* x86_64
* ppc64le

Git tree
========

Git tree with this patch series applied for testing:
https://github.com/adi-g15-ibm/linux/tree/perf-build-has

Aditya Gupta (3):
  perf build: introduce build subcommand
  perf version: update --build-options to use 'supported_features' array
  perf tests task_analyzer: check perf build for libtraceevent support

Athira Rajeev (1):
  tools/perf/tests: Update probe_vfs_getname.sh script to use perf build
    --has

 tools/perf/Build                              |  1 +
 tools/perf/builtin-build.c                    | 94 +++++++++++++++++++
 tools/perf/builtin-version.c                  | 39 ++------
 tools/perf/builtin.h                          | 47 ++++++++++
 tools/perf/perf.c                             |  1 +
 .../perf/tests/shell/lib/probe_vfs_getname.sh |  4 +-
 .../shell/record+probe_libc_inet_pton.sh      |  5 +-
 .../shell/record+script_probe_vfs_getname.sh  |  5 +-
 tools/perf/tests/shell/test_task_analyzer.sh  |  4 +-
 9 files changed, 163 insertions(+), 37 deletions(-)
 create mode 100644 tools/perf/builtin-build.c

-- 
2.41.0

Hello,

On Thu, Aug 24, 2023 at 11:11 PM Aditya Gupta <adityag@linux.ibm.com> wrote:
>
> The Problem
> ===========
>
> Currently the presence of a feature is checked with a combination of
> perf version --build-options and greps, such as:
>
>     perf version --build-options | grep " on .* HAVE_FEATURE"
>
> Proposed solution
> =================
>
> As suggested by contributors in:
> https://lore.kernel.org/linux-perf-users/ZMPWk5K63tadmDlU@kernel.org/
>
> Introduce a subcommand "perf build --has", with which
> scripts can test for presence of a feature, such as:
>
>     perf build --has HAVE_FEATURE
>
> The usage of "perf version --build-options | grep" has been replaced in two
> tests, with "perf build --has" command

I'm not sure 'perf build' is a good name, it sounds like it needs to build
something.  Maybe 'perf check --feature XXX' ?

Then we can extend the perf check command to *check* system
settings like perf_event_paranoid, kptr_restrict, nmi_watchdog
and so on, and possibly provides some advice or even change
the values easily.

What do you think?

Thanks,
Namhyung


>
> Also, to not duplicate the same feature list at multiple places, a new global
> 'supported_features' array has been introduced in builtin.h, so both commands
> 'perf build --has' and 'perf version --build-options' use the same array
>
> 'supported_features' feature is an array of 'struct feature_support', which
> also has the name of the feature, macro used to test it's presence, and a
> is_builtin member, which will be 0 if feature not built-in, and 1 if built-in
>
> Architectures Tested
> ====================
> * x86_64
> * ppc64le
>
> Git tree
> ========
>
> Git tree with this patch series applied for testing:
> https://github.com/adi-g15-ibm/linux/tree/perf-build-has
>
> Aditya Gupta (3):
>   perf build: introduce build subcommand
>   perf version: update --build-options to use 'supported_features' array
>   perf tests task_analyzer: check perf build for libtraceevent support
>
> Athira Rajeev (1):
>   tools/perf/tests: Update probe_vfs_getname.sh script to use perf build
>     --has
>
>  tools/perf/Build                              |  1 +
>  tools/perf/builtin-build.c                    | 94 +++++++++++++++++++
>  tools/perf/builtin-version.c                  | 39 ++------
>  tools/perf/builtin.h                          | 47 ++++++++++
>  tools/perf/perf.c                             |  1 +
>  .../perf/tests/shell/lib/probe_vfs_getname.sh |  4 +-
>  .../shell/record+probe_libc_inet_pton.sh      |  5 +-
>  .../shell/record+script_probe_vfs_getname.sh  |  5 +-
>  tools/perf/tests/shell/test_task_analyzer.sh  |  4 +-
>  9 files changed, 163 insertions(+), 37 deletions(-)
>  create mode 100644 tools/perf/builtin-build.c
>
> --
> 2.41.0
>

Hello Namhyung,

On Fri, Aug 25, 2023 at 10:07:28AM -0700, Namhyung Kim wrote:
> On Thu, Aug 24, 2023 at 11:11 PM Aditya Gupta <adityag@linux.ibm.com> wrote:
> >
> > The Problem
> > ===========
> >
> > Currently the presence of a feature is checked with a combination of
> > perf version --build-options and greps, such as:
> >
> >     perf version --build-options | grep " on .* HAVE_FEATURE"
> >
> > Proposed solution
> > =================
> >
> > As suggested by contributors in:
> > https://lore.kernel.org/linux-perf-users/ZMPWk5K63tadmDlU@kernel.org/
> >
> > Introduce a subcommand "perf build --has", with which
> > scripts can test for presence of a feature, such as:
> >
> >     perf build --has HAVE_FEATURE
> >
> > The usage of "perf version --build-options | grep" has been replaced in two
> > tests, with "perf build --has" command
> 
> I'm not sure 'perf build' is a good name, it sounds like it needs to build
> something.  Maybe 'perf check --feature XXX' ?
> 
> Then we can extend the perf check command to *check* system
> settings like perf_event_paranoid, kptr_restrict, nmi_watchdog
> and so on, and possibly provides some advice or even change
> the values easily.
> 
> What do you think?

Thanks for the suggestion, we agree with it.
I have sent the updated patch series, but it's again from V1 since the subcommand changed.

Patch series: https://lore.kernel.org/linux-perf-users/20230903114721.190733-1-adityag@linux.ibm.com

Thanks,
Aditya Gupta

Hello,

On Fri, Aug 25, 2023 at 10:07:28AM -0700, Namhyung Kim wrote:
> Hello,
> 
> On Thu, Aug 24, 2023 at 11:11 PM Aditya Gupta <adityag@linux.ibm.com> wrote:
> >
> > <...>
> >
> > Proposed solution
> > =================
> >
> > As suggested by contributors in:
> > https://lore.kernel.org/linux-perf-users/ZMPWk5K63tadmDlU@kernel.org/
> >
> > Introduce a subcommand "perf build --has", with which
> > scripts can test for presence of a feature, such as:
> >
> >     perf build --has HAVE_FEATURE
> >
> > <...>
> 
> I'm not sure 'perf build' is a good name, it sounds like it needs to build
> something.  Maybe 'perf check --feature XXX' ?
> 
> Then we can extend the perf check command to *check* system
> settings like perf_event_paranoid, kptr_restrict, nmi_watchdog
> and so on, and possibly provides some advice or even change
> the values easily.
> 
> What do you think?
> 

Sure, the said confusion due to 'build' makes sense. I will discuss with athira
also and post a V2 with suggested change.

And, since a new subcommand is being introduced, where do I add a
documentation, such that it can be visible in a manpage etc, similar to
perf-version(1) ?

Thanks,
Aditya Gupta