[Impact]
We need to provide the python perf module, because some applications (such as tuned) require it.
This module is implemented inside perf, provided by the kernel.
At the moment we provide a distinct perf for each kernel installed in the system. There is really no reason to do that, because perf is both backward and forward compatible, but this is a different issue and we are not going to solve it in this context and it will be addressed in a separate bug.
For now, to solve this specific issue, we need to enable the python module when we build perf (as part of the kernel build) and ship the library inside the linux-tools-<kernel_abi_version> package.
However, this brings a new problem, because we need to install the module in a standard python path (so that python applications can be able to use it in a regular way), but we need to support multiple installed versions and add some logic to transparently select the right one when a generic user-space python application uses `import perf`.
For this reason we need to provide a python wrapper module that is imported via a regular `import perf` and it transparently loads the actual python perf module, based on the kernel that is currently running.
[Test case]
Install linux-tools-<kernel_version> and run the following simple test case:
$ python -c 'import perf; [print(c) for c in perf.cpu_map()]'
[Fix]
- Enable the python perf module build during the regular kernel build
- Provide a virtual `perf` python module wrapper in linux-tools-common
[Regression potential]
We are adding a new python module to linux-tools (that is something new, we don't ship any other python module), but we are not changing anything that is already provided, so the only regression that can happen is an increased size of the linux-tools package.
[Original bug report]
The tuned package has some plugins which rely on the perf python module [1], and right now they are not working because we do not have the perf python module available in Ubuntu.
Initially, this was reported in this other bug [2], but it seems the scope of that bug is bigger than what we (Server) need for tuned. So filing this new bug as requested by the Kernel team to provide just the python module.
For reference, in Fedora it's shipped in the bin:python3-perf package:
[root@f39 ~]# rpm -ql python3-perf
/usr/lib/.build-id
/usr/lib/.build-id/80
/usr/lib/.build-id/80/9022196f598cb3327545c2d497b1d9fdf55630
/usr/lib64/python3.12/site-packages/perf-0.1-py3.12.egg-info
/usr/lib64/python3.12/site-packages/perf-0.1-py3.12.egg-info/PKG-INFO
/usr/lib64/python3.12/site-packages/perf-0.1-py3.12.egg-info/SOURCES.txt
/usr/lib64/python3.12/site-packages/perf-0.1-py3.12.egg-info/dependency_links.txt
/usr/lib64/python3.12/site-packages/perf-0.1-py3.12.egg-info/top_level.txt
/usr/lib64/python3.12/site-packages/perf.cpython-312-x86_64-linux-gnu.so
/usr/share/licenses/python3-perf
/usr/share/licenses/python3-perf/COPYING
Built from their kernel-tools package[3].
[1] https://bugs.launchpad.net/ubuntu/+source/tuned/+bug/2051290
[2] https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1613393
[3] https://src.fedoraproject.org/rpms/kernel-tools/blob/rawhide/f/kernel-tools.spec#_148
Patch sent to the kernel team mailing list for review: https:/