On Fri, 2021-11-12 at 11:39 -0300, Arnaldo Carvalho de Melo wrote:
> Em Thu, Nov 11, 2021 at 10:34:33PM -0800, Ian Rogers escreveu:
> > Hi,
>  
> > Debian currently tries to match the Linux perf tool to the version of
> > the kernel that it is being run upon. Reaching out to Ben Hutchings,
> > he explained to me that this was done back in 2010 due to kernel and
> > Linux perf incompatibilities. This was likely the case, but it was a
> > bug in the Linux perf tool that should have been fixed.

My understanding at the time was that the perf developers weren't
trying to provide backward compatibility.  If I hadn't though that, I
wouldn't have bothered with the wrapper and would have forwarded any
bug reports we got about compatibility breaks.

> > It is the goal
> > of the tool to be backward compatible. A problem with matching the
> > tool to the kernel version is that users miss out on new features and
> > fixes (this topic came up in a recent interview of the maintainer
> > Arnaldo Carvalho de Melo [1]).
>  
> > Ben Hutchings informs me that making it so that Debian ships the
> > latest Linux perf tool requires updates both to the linux-base and
> > linux source packages. The Linux perf tool also has many other often
> > optional dependencies, like libunwind, libbpf, libpfm4, libtraceevent,
> > etc. In general, having the dependency will unlock more features.
> > Linux tools has its own copies of libbpf and libtraceevent, and so
> > these may pose some versioning issues.

The libraries themselves are statically linked, so there's no conflict
there, but the libtraceevent plugins have the potential to conflict.

> We can use LIBBPF_DYNAMIC=1 to use the distro libbpf-dev package, which
> currently is going thru some growing pains as libbpf is 0.x, with
> several APIs being deprecated, others renamed, and that has been a
> source of friction, but should be past us with v1.0. Till then the perf
> codebase is being adjusted to allow it to be seamlessly built with the
> in-kernel version and with whatever libbpf-devel the distro has.
>  
> > I think it'd be great to get Debian shipping the latest version of
> > Linux perf for its users. Hopefully we can agree to change how Debian
> > packages perf currently and then work out the best way to package and
> > keep it up-to-date. I look forward to everyone's help and input.
> 
> I also keep the tarballs available at:
> 
> https://mirrors.edge.kernel.org/pub/linux/kernel/tools/perf/
> 
> Where there are instructions on how to build this detached tarball.
> 
> I regularly build perf on lots of distros, including:
> 
>   debian:9                      : Ok   gcc (Debian 6.3.0-18+deb9u1) 6.3.0 20170516 , clang version 3.8.1-24 (tags/RELEASE_381/final)
>   debian:10                     : Ok   gcc (Debian 8.3.0-6) 8.3.0 , clang version 7.0.1-8+deb10u2 (tags/RELEASE_701/final)
>   debian:11                     : Ok   gcc (Debian 10.2.1-6) 10.2.1 20210110 , Debian clang version 11.0.1-2
>   debian:experimental           : Ok   gcc (Debian 11.2.0-10) 11.2.0 , Debian clang version 11.1.0-4
>   debian:experimental-x-arm64   : Ok   aarch64-linux-gnu-gcc (Debian 11.2.0-9) 11.2.0
>   debian:experimental-x-mips    : Ok   mips-linux-gnu-gcc (Debian 10.2.1-6) 10.2.1 20210110
>   debian:experimental-x-mips64  : Ok   mips64-linux-gnuabi64-gcc (Debian 10.2.1-6) 10.2.1 20210110
>   debian:experimental-x-mipsel  : Ok   mipsel-linux-gnu-gcc (Debian 11.2.0-9) 11.2.0
[...]

I'm glad to hear that.

But whether perf tools can be built in different environments is
orthogonal to the current questions for Debian's packaging, which are:

- Do they run correctly on older kernel version?  (I think you're
  claiming they do.)
- Is there a reason to prefer building from those separate tarballs,
  rather than from kernel releases?  (I don't think there is.)


Ben.

-- 
Ben Hutchings
I say we take off; nuke the site from orbit.
It's the only way to be sure.