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.
Attachment:
signature.asc
Description: This is a digitally signed message part