On November 27, 2019 9:31:41 PM GMT-03:00, Alexei Starovoitov [off-list ref] wrote:

On Tue, Nov 26, 2019 at 5:39 PM Arnaldo Carvalho de Melo
[off-list ref] wrote:

quoted

Em Tue, Nov 26, 2019 at 03:52:28PM -0800, Jakub Kicinski escreveu:

quoted

On Tue, 26 Nov 2019 15:10:30 -0800, Stanislav Fomichev wrote:

quoted

We are using this script with python2.7, works just fine :-)
So maybe doing s/python3/python/ is the way to go, whatever
default python is installed, it should work with that.

quoted

That increases the risk someone will make a python2-only change
and break Python 3.

quoted

Python 2 is dead, I'm honestly surprised this needs to be said :)

It shouldn't have to be said, and probably it is old school to try

and

quoted

keep things portable when there is no need to use new stuff for

simple

quoted

tasks like this.

Anyway, it seems its just a matter of adding the python3 package to

the

quoted

old container images and then most of them will work with what is in
that script, what doesn't work is really old and then NO_LIBBPF=1 is

the

quoted

way to go.

In the end, kinda nothing to see here, go back to adding cool new

stuff,

quoted

lets not hold eBPF from progressing ;-P

Absolutely. I think if some distro is still using 32-bit userland it's
likely
so much behind anything modern that its kernel is equally old too
and appeal of new features (bpf or anything else) is probably low.
So if I were you I would keep 32-bit builds of perf supported, but with
minimal effort.

I try not to assume too much, just try to keep what's being tested to continue to at least build.

Re: patch itself.
I can take it as-is into bpf tree and it will be in Linus's tree in few
days.
Or I can take only tools/lib/bpf/Makefile hunk and you can take
tools/perf/MANIFEST via perf tree?
Whichever way is fine.

Take it as one, I think it's what should have been in the cset it is fixing, that way no breakage would have happened.

- Arnaldo