[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <CAP_z_Ci+Zm5v33hc-WaaLKj9ruJtBY-FMVhrcR7ZX1uJdquLvA@mail.gmail.com>
Date: Tue, 14 Jun 2022 17:10:09 -0700
From: Blake Jones <blakejones@...gle.com>
To: Jiri Olsa <olsajiri@...il.com>
Cc: Arnaldo Carvalho de Melo <acme@...nel.org>,
Mark Rutland <mark.rutland@....com>,
Alexander Shishkin <alexander.shishkin@...ux.intel.com>,
Namhyung Kim <namhyung@...nel.org>,
Ian Rogers <irogers@...gle.com>,
Peter Zijlstra <peterz@...radead.org>,
Ingo Molnar <mingo@...hat.com>,
linux-perf-users@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH RESEND] Add a "-m" option to "perf buildid-list".
On Tue, Jun 14, 2022 at 5:29 AM Jiri Olsa <olsajiri@...il.com> wrote:
> still there's kernel map included, so it's strange to me call it modules
>
> --m/--kernel-maps ?
Sure, I'll go with that.
> > > also please state that it's from running kernel
> >
> > Happy to make this change.
> >
> > > any reason why not use the dso fields directly?
> >
> > I was just following my general software engineering instincts to
> > encapsulate implementation details, so that e.g. the caller doesn't need to
> > know about details such as the "has_build_id" boolean. I haven't made
> > changes to perf before, so if that's not the preferred style, I can do it
> > a different way.
>
> we have some helpers for dso fields, but AFAICS long_name and has_build_id
> are used directly all over the place
Okay, I've switched the code over to use those fields directly.
New patch coming shortly.
Blake
Powered by blists - more mailing lists