[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAEf4BzZ9B=CPuti9smOqDKD1dRvs3Ug7h9pHupr6jFeKEppJ4g@mail.gmail.com>
Date: Mon, 29 Jul 2024 11:59:47 -0700
From: Andrii Nakryiko <andrii.nakryiko@...il.com>
To: Charlie Jenkins <charlie@...osinc.com>
Cc: Peter Zijlstra <peterz@...radead.org>, Ingo Molnar <mingo@...hat.com>,
Arnaldo Carvalho de Melo <acme@...nel.org>, Namhyung Kim <namhyung@...nel.org>,
Mark Rutland <mark.rutland@....com>,
Alexander Shishkin <alexander.shishkin@...ux.intel.com>, Jiri Olsa <jolsa@...nel.org>,
Ian Rogers <irogers@...gle.com>, Adrian Hunter <adrian.hunter@...el.com>,
Andrii Nakryiko <andrii@...nel.org>, Eduard Zingerman <eddyz87@...il.com>,
Alexei Starovoitov <ast@...nel.org>, Daniel Borkmann <daniel@...earbox.net>,
Martin KaFai Lau <martin.lau@...ux.dev>, Song Liu <song@...nel.org>,
Yonghong Song <yonghong.song@...ux.dev>, John Fastabend <john.fastabend@...il.com>,
KP Singh <kpsingh@...nel.org>, Stanislav Fomichev <sdf@...ichev.me>, Hao Luo <haoluo@...gle.com>,
linux-perf-users@...r.kernel.org, linux-kernel@...r.kernel.org,
bpf@...r.kernel.org
Subject: Re: [PATCH v2 2/8] libbpf: Move opts code into dedicated header
On Mon, Jul 29, 2024 at 10:55 AM Charlie Jenkins <charlie@...osinc.com> wrote:
>
> On Mon, Jul 29, 2024 at 10:01:05AM -0700, Andrii Nakryiko wrote:
> > On Mon, Jul 29, 2024 at 9:46 AM Charlie Jenkins <charlie@...osinc.com> wrote:
> > >
> > > Signed-off-by: Charlie Jenkins <charlie@...osinc.com>
> > > ---
> > > tools/include/tools/opts.h | 68 +++++++++++++++++++++++++++++++++++++++++
> > > tools/lib/bpf/bpf.c | 1 +
> > > tools/lib/bpf/btf.c | 1 +
> > > tools/lib/bpf/btf_dump.c | 1 +
> > > tools/lib/bpf/libbpf.c | 3 +-
> > > tools/lib/bpf/libbpf_internal.h | 48 -----------------------------
> > > tools/lib/bpf/linker.c | 1 +
> > > tools/lib/bpf/netlink.c | 1 +
> > > tools/lib/bpf/ringbuf.c | 1 +
> > > 9 files changed, 76 insertions(+), 49 deletions(-)
> > >
> >
> > Nope, sorry, I don't think I want to do this for libbpf. This will
> > just make Github synchronization trickier, and I don't really see a
> > point.
> >
> > I'm totally fine with libperf making a copy of these helpers, though
> > (this is not complicated or tricky code). I also don't think it will
> > change much, so there is little risk of any sort of divergence.
>
> I did this because there were two comments on the previous version of
> this patch that asked to change the functions that were copied over. I
> had a couple of choices, have the implementations diverge, not change
> the implementation in perf to keep it the same as bpf, update both perf
> and bpf, or share the implementations. I figured the last option was the
> best to avoid immediate divergence. However, both of the comments can be
> safely ignored, and also perhaps divergence doesn't matter.
>
I mean, feel free to diverge. First and foremost the code has to make
sense to specific library and specific use case. If libperf has some
extra things that it needs to enforce or check, by all means. I just
want to avoid unnecessary code sharing, given the code isn't tricky or
complicated, but will complicate libbpf's sync story to Github (libbpf
kind of lives in two places, kernel repo and Github repo).
> - Charlie
>
> >
> > [...]
Powered by blists - more mailing lists