linux-kernel - Re: [PATCH 27/35] perf tools: Add perf_event__is

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <CAP-5=fVUHdDZi_EHCe2Ko-7FZjbdaoNvA-u-CrZE4Vs6O=fNAw@mail.gmail.com>
Date:   Wed, 20 Jul 2022 07:56:24 -0700
From:   Ian Rogers <irogers@...gle.com>
To:     Arnaldo Carvalho de Melo <acme@...nel.org>
Cc:     Adrian Hunter <adrian.hunter@...el.com>,
        Jiri Olsa <jolsa@...hat.com>,
        Namhyung Kim <namhyung@...nel.org>,
        Andi Kleen <ak@...ux.intel.com>, linux-kernel@...r.kernel.org,
        kvm@...r.kernel.org
Subject: Re: [PATCH 27/35] perf tools: Add perf_event__is_guest()

On Wed, Jul 20, 2022 at 7:06 AM Arnaldo Carvalho de Melo
<acme@...nel.org> wrote:
>
> Em Tue, Jul 19, 2022 at 06:11:47PM -0700, Ian Rogers escreveu:
> > On Mon, Jul 11, 2022 at 2:33 AM Adrian Hunter <adrian.hunter@...el.com> wrote:
> > >
> > > Add a helper function to determine if an event is a guest event.
> > >
> > > Signed-off-by: Adrian Hunter <adrian.hunter@...el.com>
> > > ---
> > >  tools/perf/util/event.h | 21 +++++++++++++++++++++
> > >  1 file changed, 21 insertions(+)
> > >
> > > diff --git a/tools/perf/util/event.h b/tools/perf/util/event.h
> > > index a660f304f83c..a7b0931d5137 100644
> > > --- a/tools/perf/util/event.h
> > > +++ b/tools/perf/util/event.h
> >
> > Would this be better under tools/lib/perf ?
>
> In general I think we should move things to libperf when a user requests
> it, i.e. it'll be needed in a tool that uses libperf.

The perf_event_header is defined in libperf. If we're worried about
exposing the API, we could keep it in the internal include files. To
explain my thinking, if something like cpumap or perf_event_header
live in libperf, then it makes sense to me that the structs, accessors
and the like also live there. Having the code standing in both perf
and libperf is a transitory state we should be working to remove.

I don't see this as a big deal, so don't mind the code not being in libperf :-)

Thanks,
Ian

> - Arnaldo
>
> > Thanks,
> > Ian
> >
> > > @@ -484,4 +484,25 @@ void arch_perf_synthesize_sample_weight(const struct perf_sample *data, __u64 *a
> > >  const char *arch_perf_header_entry(const char *se_header);
> > >  int arch_support_sort_key(const char *sort_key);
> > >
> > > +static inline bool perf_event_header__cpumode_is_guest(u8 cpumode)
> > > +{
> > > +       return cpumode == PERF_RECORD_MISC_GUEST_KERNEL ||
> > > +              cpumode == PERF_RECORD_MISC_GUEST_USER;
> > > +}
> > > +
> > > +static inline bool perf_event_header__misc_is_guest(u16 misc)
> > > +{
> > > +       return perf_event_header__cpumode_is_guest(misc & PERF_RECORD_MISC_CPUMODE_MASK);
> > > +}
> > > +
> > > +static inline bool perf_event_header__is_guest(const struct perf_event_header *header)
> > > +{
> > > +       return perf_event_header__misc_is_guest(header->misc);
> > > +}
> > > +
> > > +static inline bool perf_event__is_guest(const union perf_event *event)
> > > +{
> > > +       return perf_event_header__is_guest(&event->header);
> > > +}
> > > +
> > >  #endif /* __PERF_RECORD_H */
> > > --
> > > 2.25.1
> > >
>
> --
>
> - Arnaldo