Re: [PATCH v2 0/4] Add SWIG Bindings to libcpupower

[Shuah Khan <skhan@linuxfoundation.org>]

On 9/4/24 06:41, Shuah Khan wrote:
> On 8/27/24 00:24, 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. Providing bindings for scripting languages is a common feature
>> to make use of libraries more accessible to more users and programs. My team
>> specifically wants to expand the features of rteval. rteval is a Python program
>> used to measure real time 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. Since SWIG requires the .o files created by libcpupower at
>> compilation it makes sense to include this in the cpupower directory so that
>> others can make use of them.
>>
>> The V2 of this patchset includes:
>> * the full definition of libcpupower headers that is needed for the bindings
>> * dummy implementation in C of a function listed in the header of libcpupower
>> (requested by Shuah Khan)
>> * test_raw_pylibcpupower.py demonstrates an example of using the bindings
>> * adding myself and John Kacur to the cpupower section of the maintainers file
>> (requested by Shuah Khan)
>> * addressed review comments about doc, makefile, and maintainers file
>> * small style and other fixes
>>
>> The name raw_pylibcpupower is used because a wrapper `pylibcpupower` may be
>> needed to make the bindings more 'pythonic' in the future. The bindings folder
>> is used because Go or Perl bindings may be useful for other users in the
>> future.
>>
>> Note that while SWIG itself is GPL v3+ licensed; the resulting output, the
>> bindings code, has the same license as the .o files used to generate the
>> bindings (GPL v2 only). Please see
>> https://swig.org/legal.html
>> and
>> https://lore.kernel.org/linux-pm/Zqv9BOjxLAgyNP5B@hatbackup/#t
>> for more details on the license.
>>
>> Sincerely,
>> John Wyatt
>> Software Engineer, Core Kernel
>> Red Hat
>>
>> John B. Wyatt IV (4):
>>    Add SWIG bindings files for libcpupower
>>    Implement dummy function for SWIG to accept the full library
>>      definitions
>>    Include test_raw_pylibcpupower.py
>>    MAINTAINERS: Add Maintainers for SWIG Python bindings
>>
>>   MAINTAINERS                                   |   3 +
>>   .../power/cpupower/bindings/python/.gitignore |   8 +
>>   tools/power/cpupower/bindings/python/Makefile |  31 +++
>>   tools/power/cpupower/bindings/python/README   |  59 +++++
>>   .../bindings/python/raw_pylibcpupower.i       | 247 ++++++++++++++++++
>>   .../bindings/python/test_raw_pylibcpupower.py |  42 +++
>>   tools/power/cpupower/lib/powercap.c           |   8 +
>>   7 files changed, 398 insertions(+)
>>   create mode 100644 tools/power/cpupower/bindings/python/.gitignore
>>   create mode 100644 tools/power/cpupower/bindings/python/Makefile
>>   create mode 100644 tools/power/cpupower/bindings/python/README
>>   create mode 100644 tools/power/cpupower/bindings/python/raw_pylibcpupower.i
>>   create mode 100755 tools/power/cpupower/bindings/python/test_raw_pylibcpupower.py
>>
> 

Noticed Rafael isn't on this thread. Adding now to keep him
in the loop.

cpupower pull request go through Rafael's tree.

> Couple of things to address:
> 
> 1. I noticed none of the patches have the subsystem prefix:
>    pm:cpupower is the right prefix for patch subject for all
>    the patches except the MAINTAINERS file
> 
> I will pull the fix  "Implement dummy function for SWIG to accept
> the full library" Patch 2 in your series.
> 
> I want this subject changed to just fix as it is a problem irrespective
> of SWIG - we have a missing function. Subject would be as follows:
> 
> ""pm:cpupower: Add missing powercap_set_enabled() stub function"
> 
> Make this the first patch in the series. I will send this up for
> Linux 6.11-rc7 or Linux 6.12-rc1
> 
> Depending on how the timelines for merge window work, expect the
> series to land in Linux 6.13-rc1. I would prefer to delay it anyway
> so we can get some soaking in next.
> 

thanks,
-- Shuah