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

From: Shuah Khan
Date: Tue Jul 30 2024 - 16:48:53 EST


Hi,

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?

This RFC provides a limited subset of bindings as a demonstration. The second
commit provides a Python test script to verify the bindings. I wanted to get
feedback on this before implementing (and possibly testing) the entire library.

The name raw_pylibcpupower is used because this is a demonstration example that
only provides direct bindings for a few functions. A wrapper `pylibcpupower`
may be needed to make the bindings more 'pythonic'. The bindings folder is used
because Go bindings may be useful for Kubernetes or OpenShift in the future.

How should the bindings be built? The current example requires the makefile
in cpupower directory be run first to generate the .o files needed before
running the makefile in the python directory in a seperate step. Would the
maintainers prefer the two makefiles integrated?

I can't answer this question until I understand the licensing.
However, I would lean towards keeping them separate.


Another question is do you want more test files like the .py example? Would
this be used as part of a greater test suite?

I would like to see document outlining the dependencies and examples of how
this would be used. I see the README which says that

"Next you will need to install SWIG. Using Fedora:"

The document will have to include more than Fedora instructions. Instead
of a README I would like to see a document.

Before we go any further - we have the licensing implications to figure out.


Note that while SWIG itself is GPL v3+ licensed; the resulting output, the
bindings code, is permissively licensed. Please see
https://swig.org/legal.html for more details.

Adding Linus and Greg for their feedback and input on this proposal.

What does it mean by "the resulting output, the bindings code is
permissively licensed."

I would like to get a better understanding of the licensing angle
since this code adds dependency on SWIG which is GPL v3+ to build
the proposed python bindings.

thanks,
-- Shuah