Re: [PATCH] perf data ctf: replace libbabeltrace with babeltrace2-ctf-writer
From: Ian Rogers
Date: Wed May 20 2026 - 12:28:25 EST
On Wed, May 13, 2026 at 9:06 AM Ian Rogers <irogers@xxxxxxxxxx> wrote:
> On Wed, May 13, 2026 at 7:14 AM Michael Jeanson <mjeanson@xxxxxxxxxxxx> 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.
Thanks,
Ian