* Re: a few libperf questions
2022-06-02 16:25 ` Ian Rogers
@ 2022-06-02 20:54 ` Vince Weaver
2022-06-03 9:32 ` Jiri Olsa
1 sibling, 0 replies; 4+ messages in thread
From: Vince Weaver @ 2022-06-02 20:54 UTC (permalink / raw)
To: Ian Rogers
Cc: linux-perf-users, Jiri Olsa, Arnaldo Carvalho de Melo,
Peter Zijlstra
On Thu, 2 Jun 2022, Ian Rogers wrote:
> > 1. What's the licensing of libperf? Is it GPLv2?
> >
> > PAPI is BSD licensed.
> > This is something that actually pushes us to libperf
> > because if I wanted to (for example) implement the new
> > ARM rdpmc code I can't just copy it in to PAPI but
> > would have to re-implement from scratch
>
> I believe that as code in libperf was copied from perf it retains the
> GPL-2.0-only license. Some new code is "LGPL-2.1 OR BSD-2-Clause",
> which makes more sense and would align libperf with libbpf. We've
> talked about rewriting this code in Rust, perhaps when that is done
> the more permissive license could be used.
I was looking into this more, the various files have different licenses
linux.git/tools/lib/perf$ cat *.c Makefile | grep SPDX | uniq
// SPDX-License-Identifier: GPL-2.0-only
// SPDX-License-Identifier: GPL-2.0
# SPDX-License-Identifier: (LGPL-2.1 OR BSD-2-Clause)
and this disagrees with what the documentation says:
linux.git/tools/lib/perf/Documentation/libperf-counting.txt
LICENSE
-------
libperf is Free Software licensed under the GNU LGPL 2.1
I don't know which of these needs to be fixed to be more consistent.
Vince Weaver
vincent.weaver@maine.edu
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: a few libperf questions
2022-06-02 16:25 ` Ian Rogers
2022-06-02 20:54 ` Vince Weaver
@ 2022-06-03 9:32 ` Jiri Olsa
1 sibling, 0 replies; 4+ messages in thread
From: Jiri Olsa @ 2022-06-03 9:32 UTC (permalink / raw)
To: Ian Rogers
Cc: Vince Weaver, linux-perf-users, Arnaldo Carvalho de Melo,
Peter Zijlstra
On Thu, Jun 02, 2022 at 09:25:46AM -0700, Ian Rogers wrote:
> On Thu, Jun 2, 2022 at 8:38 AM Vince Weaver <vincent.weaver@maine.edu> wrote:
> >
> > Hello
> >
> > I work on various perf-related tools in the HPC community, most notably
> > the PAPI performance library.
> >
> > Currently PAPI maintains its own independent code for working with
> > perf_event_open(), but with the advent of libperf I was looking into maybe
> > linking against libperf to avoid all the code/work duplication. So I had
> > a few questions.
> >
> > 1. What's the licensing of libperf? Is it GPLv2?
> >
> > PAPI is BSD licensed.
> > This is something that actually pushes us to libperf
> > because if I wanted to (for example) implement the new
> > ARM rdpmc code I can't just copy it in to PAPI but
> > would have to re-implement from scratch
>
> I believe that as code in libperf was copied from perf it retains the
> GPL-2.0-only license. Some new code is "LGPL-2.1 OR BSD-2-Clause",
> which makes more sense and would align libperf with libbpf. We've
> talked about rewriting this code in Rust, perhaps when that is done
> the more permissive license could be used.
yep, all the libperf code was copied from perf, so should have the
same license
>
> > 2. Is it expected that distributions will start shipping
> > libperf? As part of perf or otherwise?
> >
> > Telling HPC users they need to dowload an entire
> > kernel tree just to build libperf is seen as a huge
> > obstacle for many, and just including a snapshot
> > of the code into our code tree again starts having
> > licensing issues.
>
> There is a Makefile and an install step, however, I would say libperf
> is *not* ready to be distributed. There was a lot of cleanup effort to
> make libbpf 1.0 and similar should happen to libperf. I particularly
it's currently packaged as sub package of kernel-tools in fedora:
[jolsa@krava ~]$ rpm -qi libperf
Name : libperf
Version : 5.17.11
Release : 200.fc35
Architecture: x86_64
Install Date: Mon 30 May 2022 09:30:12 AM CEST
Group : Unspecified
Size : 109230
License : GPLv2
Signature : RSA/SHA256, Wed 25 May 2022 10:46:33 PM CEST, Key ID db4639719867c58f
Source RPM : kernel-tools-5.17.11-200.fc35.src.rpm
Build Date : Wed 25 May 2022 10:15:25 PM CEST
Build Host : bkernel01.iad2.fedoraproject.org
Packager : Fedora Project
Vendor : Fedora Project
URL : http://www.kernel.org/
Bug URL : https://bugz.fedoraproject.org/kernel-tools
Summary : The perf library from kernel source
Description :
This package contains the kernel source perf library.
not sure about other distros
> loathe perf_cpu_map__empty, which isn't doing what it says on the tin.
nice, that one should be easy to fix ;-)
jirka
>
> > 3. Is libperf planned to be backwards compatible with old kernels,
> > or will it be tied to whatever kernel it is shipped with?
> > Will it have ABI-stable releases?
> >
> > Sort of like with perf, I know only supporting the most
> > recent kernel makes life easier for the kernel developers
> > but it does make for a library versioning nightmare
> > especially if trying to support people on older
> > distro releases.
>
> There is a myth that comes from Debian that perf only supports the
> running kernel. This is wrong and means that bug fixes, improvements,
> etc. are missed out on. This thread discusses it:
> https://lore.kernel.org/linux-perf-users/CAP-5=fW7La9ZNv8Z6LHRRNXne4+dWK6dR1ye2P=zETFELtK=fg@mail.gmail.com/
> It would be hugely impactful if someone could fix this, as a lot of
> other distributions follow Debian.
>
> Given perf doesn't have this problem and it is using libperf, I don't
> think libperf has the problem.
yes, same rules as for perf.. it should be backward compatible
jirka
>
> > I'm going to try to see if I can get a libperf backend for PAPI going and
> > maybe try to get some of the other HPC parties involved (they tend to not
> > want to deal with kernel development directly for some reason) but I'm not
> > sure if they're going to like how closely bound libperf is to
> > the kernel tree.
>
> Sounds good. The code is in the kernel tree but I'm not sure it is
> "bound" to it.
>
> Thanks,
> Ian
>
> > Vince Weaver
> > vincent.weaver@maine.edu
^ permalink raw reply [flat|nested] 4+ messages in thread