Re: [PATCH] perf data ctf: replace libbabeltrace with babeltrace2-ctf-writer

[Arnaldo Carvalho de Melo <acme@kernel.org>]

On Wed, May 20, 2026 at 11:12:37AM -0700, Ian Rogers wrote:
> On Wed, May 20, 2026 at 10:58 AM Michael Jeanson <mjeanson@efficios.com> wrote:
> >
> > On 2026-05-20 12:13, Ian Rogers wrote:
> > > On Wed, May 13, 2026 at 9:06 AM Ian Rogers <irogers@google.com> wrote:
> > >> On Wed, May 13, 2026 at 7:14 AM Michael Jeanson <mjeanson@efficios.com> wrote:
> > >>> On 2026-05-12 17:54, Ian Rogers wrote:
> > >>>> This is cool, I'm surprised at how non-invasive the change is. I'd
> > >>>> done a similar thing but keeping both babeltrace 1 and 2. I'll post my
> > >>>> WIP in reply just as a heads up, but I have to do much more heavy
> > >>>> engineering.
> > >>>
> > >>> I think I can rework this to try babeltrace2-ctf-writer first and fall
> > >>> back on libbabeltrace1. The change is non-invasive because
> > >>> bt2-ctf-writer is basically just a compat API for the ctf-writer of bt1
> > >>> but it doesn't expose any of the new features of bt2.
> > >>>
> > >>> Your WIP patch that uses the proper libbabeltrace2 API is definitely the
> > >>> way to go for the long term. In the meantime would you like a v2 of this
> > >>> patch?
> > >>
> > >> We have a problem with the perf tool in that it carries too much
> > >> baggage due to its library dependencies, so I'd prefer we stick with
> > >> v2 support and your cleaner/simpler patch. I'm also hugely
> > >> appreciative of the work you've put in! I'm too busy to review my own
> > >> work right now, and cleaning this up ASAP offers an advantage.
> > > ...
> > >>
> > >> * We support libbfd although libbfd is GPLv3 and license incompatible
> > >> with perf, which is mainly GPLv2. We carry around libunwind support
> > >> but that project appears unmaintained. We have LLVM support but the
> > >> LLVM dependency is huge in terms of size and dependencies it brings
> > >> in, so people avoid building with it, etc.
> > >
> > > What's the plan here? I'd prefer to carry the v1 patch, ie let's lose
> > > libbabeltrace (version 1) as a dependency.
> >
> > I think I misunderstood you, I thought you wanted to keep the bt1
> > support as a fallback. I'm fine with either version of the patch being
> > merged.
> >
> > I can send an updated version of the v1 patch addressing your review
> > comments.
> 
> Arnaldo, Namhyung, do you mind losing libbabeltrace v1 support? As the
> commit message states:
> 
>   The 1.x branch of Babeltrace has been superseded by 2.x in 2020 and has
>   been unmaintained since 2022, efforts have started to remove it from
>   popular distributions.
> 
> My choice would be to go with the v1 patch with the few fixes I'd mentioned.

Right, this is from the people working directly in babeltrace, so I'll
take their advice, Michael, can you please address Ian's comments, check
that it applies cleanly to perf-tools-next and resubmit, please?

- Arnaldo