[U/N,0/2] Provide python perf module

[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:

 $ python3 -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.

On Fri, Mar 22, 2024 at 11:47 AM Andrea Righi
<andrea.righi@canonical.com> wrote:
>
> [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:
>
>  $ python3 -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.

The perf module loader in patch 2 looks good, but there's a typo in
patch 1. In debian.master/rules.d/s390x.mk, it has "to_tools" on two
lines as opposed to "do_tools" like the rest.

-Kevin

On Mon, Mar 25, 2024 at 11:35:04AM -0400, Kevin Becker wrote:
> On Fri, Mar 22, 2024 at 11:47 AM Andrea Righi
> <andrea.righi@canonical.com> wrote:
> >
> > [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:
> >
> >  $ python3 -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.
> 
> The perf module loader in patch 2 looks good, but there's a typo in
> patch 1. In debian.master/rules.d/s390x.mk, it has "to_tools" on two
> lines as opposed to "do_tools" like the rest.

Thanks for noticing this!

I've already pushed an updated version noble/master-next.

-Andrea