All of lore.kernel.org
 help / color / mirror / Atom feed
From: Arnaldo Carvalho de Melo <acme@kernel.org>
To: Aditya Gupta <adityag@linux.ibm.com>
Cc: jolsa@kernel.org, irogers@google.com, namhyung@kernel.org,
	linux-perf-users@vger.kernel.org, maddy@linux.ibm.com,
	atrajeev@linux.vnet.ibm.com, kjain@linux.ibm.com,
	disgoel@linux.vnet.ibm.com
Subject: Re: [PATCH v11 1/4] perf check: introduce check subcommand
Date: Fri, 28 Jun 2024 11:24:53 -0300	[thread overview]
Message-ID: <Zn7HtaJb3NL2k5YG@x1> (raw)
In-Reply-To: <Zn7GsEKwLxn5bMyN@x1>

On Fri, Jun 28, 2024 at 11:20:35AM -0300, Arnaldo Carvalho de Melo wrote:
> On Fri, Jun 28, 2024 at 11:15:57AM -0300, Arnaldo Carvalho de Melo wrote:
> > On Fri, Jun 28, 2024 at 11:12:16AM -0300, Arnaldo Carvalho de Melo wrote:
> > > On Thu, Jun 27, 2024 at 03:36:41PM +0530, Aditya Gupta wrote:
> > > > 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"
> > > > 
> > > > Instead of this, introduce a subcommand "perf check feature", with which
> > > > scripts can test for presence of a feature, such as:
> > > > 
> > > >     perf check feature HAVE_FEATURE
> > > > 
> > > > 'perf check feature' command is expected to have exit status of 0 if
> > > > feature is built-in, and 1 if it's not built-in or if feature is not known.
> > > > 
> > > > Multiple features can also be passed as a comma-separated list, in which
> > > > case the exit status will be 1 only if all of the passed features are
> > > > built-in. For example, with below command, it will have exit status of 0
> > > > only if both libtraceevent and bpf are enabled, else 1 in all other cases
> > > > 
> > > >     perf check feature libtraceevent,bpf
> > > > 
> > > > The arguments are case-insensitive.
> > > > An array 'supported_features' has also been introduced that can be used by
> > > > other commands like 'perf version --build-options', so that new features
> > > > can be added in one place, with the array
> > 
> > Now testing it with just this first patch applied:
> > 
> > ⬢[acme@toolbox perf-tools-next]$ perf check feature bpf
> >                    bpf: [ on  ]  # HAVE_LIBBPF_SUPPORT
> > ⬢[acme@toolbox perf-tools-next]$ echo $?
> > 0
> > ⬢[acme@toolbox perf-tools-next]$ perf check bpf,libtrafs
> > 
> >  Usage: perf check [<subcommand>] [<options>]
> > 
> >     -q, --quiet           do not show any warnings or messages
> > 
> > ⬢[acme@toolbox perf-tools-next]$
> > 
> > 
> > I don't see a way to list what features can be tested against, would be
> > great to have.
> > 
> > Also it just says that the usage is wrong, no indication as to why, I
> > think this would be more informative:
> > 
> > 
> > ⬢[acme@toolbox perf-tools-next]$ perf check bpf,libtrafs
> > Unkown feature 'libtrafs', please use 'perf check feature --list' to see which ones are available.

Or:

⬢[acme@toolbox perf-tools-next]$ perf version --build-options
perf version 6.10.rc1.g25cd7047ff7b
                 dwarf: [ on  ]  # HAVE_DWARF_SUPPORT
    dwarf_getlocations: [ on  ]  # HAVE_DWARF_GETLOCATIONS_SUPPORT
         syscall_table: [ on  ]  # HAVE_SYSCALL_TABLE_SUPPORT
                libbfd: [ OFF ]  # HAVE_LIBBFD_SUPPORT
            debuginfod: [ on  ]  # HAVE_DEBUGINFOD_SUPPORT
                libelf: [ on  ]  # HAVE_LIBELF_SUPPORT
               libnuma: [ on  ]  # HAVE_LIBNUMA_SUPPORT
numa_num_possible_cpus: [ on  ]  # HAVE_LIBNUMA_SUPPORT
               libperl: [ on  ]  # HAVE_LIBPERL_SUPPORT
             libpython: [ on  ]  # HAVE_LIBPYTHON_SUPPORT
              libslang: [ on  ]  # HAVE_SLANG_SUPPORT
             libcrypto: [ on  ]  # HAVE_LIBCRYPTO_SUPPORT
             libunwind: [ on  ]  # HAVE_LIBUNWIND_SUPPORT
    libdw-dwarf-unwind: [ on  ]  # HAVE_DWARF_SUPPORT
           libcapstone: [ on  ]  # HAVE_LIBCAPSTONE_SUPPORT
                  zlib: [ on  ]  # HAVE_ZLIB_SUPPORT
                  lzma: [ on  ]  # HAVE_LZMA_SUPPORT
             get_cpuid: [ on  ]  # HAVE_AUXTRACE_SUPPORT
                   bpf: [ on  ]  # HAVE_LIBBPF_SUPPORT
                   aio: [ on  ]  # HAVE_AIO_SUPPORT
                  zstd: [ on  ]  # HAVE_ZSTD_SUPPORT
               libpfm4: [ on  ]  # HAVE_LIBPFM
         libtraceevent: [ on  ]  # HAVE_LIBTRACEEVENT
         bpf_skeletons: [ on  ]  # HAVE_BPF_SKEL
  dwarf-unwind-support: [ on  ]  # HAVE_DWARF_UNWIND_SUPPORT
            libopencsd: [ on  ]  # HAVE_CSTRACE_SUPPORT
⬢[acme@toolbox perf-tools-next]$

I.e.:

Unkown feature 'libtrafs', please use 'perf version --build-options' to see which ones are available.

And while looking at it:

             get_cpuid: [ on  ]  # HAVE_AUXTRACE_SUPPORT

This looks wrong, no? Or at least confusing, have to check the source
code...

Also:

               libnuma: [ on  ]  # HAVE_LIBNUMA_SUPPORT
numa_num_possible_cpus: [ on  ]  # HAVE_LIBNUMA_SUPPORT

- Arnaldo

> > ⬢[acme@toolbox perf-tools-next]$
> 
> Ah, to clarify, these comments are for the v12 series even being replies
> to the v11 thread, I'll move to the v12 e-mail thread. Using b4 I got
> the latest version, v12:
> 
> Cover: ./v12_20240628_adityag_introduce_perf_check_subcommand.cover
>  Link: https://lore.kernel.org/r/20240628064236.1123851-1-adityag@linux.ibm.com
>  Base: applies clean to current tree
>        git checkout -b v12_20240628_adityag_linux_ibm_com HEAD
>        git am ./v12_20240628_adityag_introduce_perf_check_subcommand.mbx
> ⬢[acme@toolbox perf-tools-next]$        git am ./v12_20240628_adityag_introduce_perf_check_subcommand.mbx
> Applying: perf check: introduce check subcommand
> Applying: perf version: update --build-options to use 'supported_features' array
> Applying: perf tests task_analyzer: use perf check for libtraceevent support
> Applying: tools/perf/tests: Update probe_vfs_getname.sh script to use perf check feature
> ⬢[acme@toolbox perf-tools-next]$

  reply	other threads:[~2024-06-28 14:24 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-06-27 10:06 [PATCH v11 0/4] Introduce perf check subcommand Aditya Gupta
2024-06-27 10:06 ` [PATCH v11 1/4] perf check: introduce " Aditya Gupta
2024-06-28 14:12   ` Arnaldo Carvalho de Melo
2024-06-28 14:15     ` Arnaldo Carvalho de Melo
2024-06-28 14:20       ` Arnaldo Carvalho de Melo
2024-06-28 14:24         ` Arnaldo Carvalho de Melo [this message]
2024-06-28 18:28           ` Namhyung Kim
2024-06-28 19:28             ` Arnaldo Carvalho de Melo
2024-06-30 14:08               ` Aditya Gupta
2024-07-02 21:28                 ` Arnaldo Carvalho de Melo
2024-06-30 11:01           ` Aditya Gupta
2024-06-30 10:43         ` Aditya Gupta
2024-06-30 10:41       ` Aditya Gupta
2024-06-30 10:30     ` Aditya Gupta
2024-06-27 10:06 ` [PATCH v11 2/4] perf version: update --build-options to use 'supported_features' array Aditya Gupta
2024-06-27 10:06 ` [PATCH v11 3/4] perf tests task_analyzer: use perf check for libtraceevent support Aditya Gupta
2024-06-27 10:06 ` [PATCH v11 4/4] tools/perf/tests: Update probe_vfs_getname.sh script to use perf check feature 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=Zn7HtaJb3NL2k5YG@x1 \
    --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-perf-users@vger.kernel.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 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.