Re: [PATCH 0/2][RFC] Add SWIG Bindings to libcpupower

["John B. Wyatt IV" <jwyatt@redhat.com>]

Adding Arnaldo to the CC list.

On Sun, Aug 04, 2024 at 10:54:10AM +0200, Greg Kroah-Hartman wrote:
> On Thu, Aug 01, 2024 at 05:24:20PM -0400, John B. Wyatt IV wrote:
> > > On 7/24/24 16:11, John B. Wyatt IV wrote:
> > > > SWIG is a tool packaged in Fedora and other distros that can generate
> > > > bindings from C and C++ code for several languages including Python,
> > > > Perl, and Go. We at Red Hat are interested in adding binding support to
> > > > libcpupower so Python tools like rteval or tuned can make easy use of it.
> > > > 
> > > 
> > > Can you elaborate on the use-case and what rteval currently does and
> > > how it could benefit from using libcpupower with the bindings?
> > 
> > rteval is a Python program used to measure realtime performance. We wanted to
> > test the effect of enabling some levels of idle-stat to see how it affects
> > latency, and didn't want to reinvent the wheel. We thought that the Python
> > bindings could be useful to other people as well who might want to call
> > cpupower too from Python. I did some testing and was able to achieve this with
> > SWIG. We sent the patchset to see what folks thought about this.
> 
> Is this going to require a built-time dependency on SWIG?  If not, when
> would it be run

It is optional, and based on my conversation with Shuah; the bindings will be
in a seperate makefile. It would be ran after running cpupower's
makefile, seperately. (But one can call the other.)

> and who will be in charge of running it and updating the bindings?

That would be myself. If I no longer wish to continue I would reassign it to
another person here on the real-time team at Red Hat. John Kacur (whom I am
working with on rteval) is fine with being listed as a backup contact.

The bindings would need to be updated every time one of the functions or data
structures listed in the .i file changes. But it can be as simple as copying the
changed declaration from the header file to the .i file to resolve.

> And finally, why do we need these at all?

To provide bindings for Python programs like rteval to easily interface with
libcpupower. It is very common for userspace programs to include bindings to
scripting languages.

> You are saying these are new
> tests that external tools will be using, but why, if external tools are
> required to run them, are they needed in the kernel tree at all?  Why
> isn't this just another external test-suite that people who care about
> measuring this type of thing going to just run on their own if desired?

SWIG the tool requires the .o files compiled from libcpupower to generate
bindings. Since we need these artifacts from a packaging and usability perspective
it makes sense to include the bindings source code along in a seperate directory
with the cpupower source code to generate the builds for them at the same time.
The source code is: the .i definitions file, any future Python wrapper helpers
around the bindings needed by SWIG, and the documentation.

Why SWIG? It was chosen for this project because of:

1) Many Python bindings generators are strickly Apache2 or GPL v3 licensed; and
they may inject code into the bindings binary that will create a license conflict
with the GPL v2. Swig was far more clear about the license status of the
generated bindings. As described above:
https://lore.kernel.org/linux-pm/1f5c24b6-f3ee-4863-8b7a-49344a550206@linuxfoundation.org/T/#mb7170232fb429fc242bb45c8d3d4d5ed47f0c59f

2) It's extensive documentation. This is the Python section:
https://www.swig.org/Doc4.2/Python.html#Python

3) Support: SWIG has been around since 1996 and had a release 5 months ago. It's
length of time and the acitvity in it's community makes it unlikely SWIG will
lose support by it's developers anytime soon.

4) This RFC demonstrates how quickly and with little work you can generate
bindings for an existing C project with no code changes to that project. :-)
There were issues getting other Python bindings generators to work as
described in their documentation.

-- 
Sincerely,
John Wyatt
Software Engineer, Core Kernel
Red Hat