From: Arnaldo Carvalho de Melo <acme@kernel.org>
To: Ian Rogers <irogers@google.com>
Cc: Namhyung Kim <namhyung@kernel.org>,
linux-perf-users <linux-perf-users@vger.kernel.org>,
Song Liu <song@kernel.org>,
Adrian Hunter <adrian.hunter@intel.com>,
Jiri Olsa <jolsa@kernel.org>,
Kan Liang <kan.liang@linux.intel.com>,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH 1/1] perf bpf: Move BPF disassembly routines to separate file to avoid clash with capstone bpf headers
Date: Wed, 31 Jul 2024 15:49:13 -0300 [thread overview]
Message-ID: <ZqqHKWPcW3TvSQoQ@x1> (raw)
In-Reply-To: <CAP-5=fXX5RUgoXR2v4YPYQWJi=A1LejJ-MfhKqe+es+SR3WyyQ@mail.gmail.com>
On Wed, Jul 31, 2024 at 10:35:12AM -0700, Ian Rogers wrote:
> On Wed, Jul 31, 2024 at 10:08 AM Namhyung Kim <namhyung@kernel.org> wrote:
> >
> > On Wed, Jul 31, 2024 at 8:12 AM Arnaldo Carvalho de Melo
> > <acme@kernel.org> wrote:
> [snip]
> > > +perf-util-y += disasm_bpf.o
> >
> > I think this can be gated by LIBBFD and LIBBPF config, but not sure
> > it can express the both requirements easily.
>
> Should we gate things on libbfd? Given we can't distribute a binary
> linked against it, I support deleting all libbfd support. Fixes like
> this show the pain in carrying it.
I thought about it, but the problem at hand was that library A clashed
with library B for a namespace, so I fixed just that problem.
I agree that as soon as we reimplement the features that now are only
available with libbfd we should remove that code, now it is even more
isolated.
- Arnaldo
next prev parent reply other threads:[~2024-07-31 18:49 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-07-31 15:12 [PATCH 1/1] perf bpf: Move BPF disassembly routines to separate file to avoid clash with capstone bpf headers Arnaldo Carvalho de Melo
2024-07-31 15:45 ` Arnaldo Carvalho de Melo
2024-07-31 17:07 ` Namhyung Kim
2024-07-31 17:35 ` Ian Rogers
2024-07-31 18:49 ` Arnaldo Carvalho de Melo [this message]
2024-07-31 18:51 ` Arnaldo Carvalho de Melo
2024-08-01 15:18 ` Ian Rogers
2024-08-01 17:38 ` Arnaldo Carvalho de Melo
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=ZqqHKWPcW3TvSQoQ@x1 \
--to=acme@kernel.org \
--cc=adrian.hunter@intel.com \
--cc=irogers@google.com \
--cc=jolsa@kernel.org \
--cc=kan.liang@linux.intel.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-perf-users@vger.kernel.org \
--cc=namhyung@kernel.org \
--cc=song@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.