Em Wed, Nov 27, 2019 at 10:55:31AM -0800, Alexei Starovoitov escreveu: > On Wed, Nov 27, 2019 at 10:45 AM Arnaldo Carvalho de Melo > <acme@xxxxxxxxxx> wrote: > > > > Em Wed, Nov 27, 2019 at 08:39:28AM -0800, Alexei Starovoitov escreveu: > > > On Wed, Nov 27, 2019 at 5:45 AM Arnaldo Carvalho de Melo > > > <acme@xxxxxxxxxx> wrote: > > > > > > > > Another fix I'm carrying in my perf/core branch, > > > > > Why in perf/core? > > > I very much prefer all libbpf patches to go via normal route via bpf/net trees. > > > We had enough conflicts in this merge window. Let's avoid them. > > > > Humm, if we both carry the same patch the merge process can do its magic > > and nobody gets hurt? Besides these are really minor things, no? > > I thought so too, but learned the hard lesson recently. > We should try to avoid that as much as possible. > Andrii's is fixing stuff in the same lines: > https://patchwork.ozlabs.org/patch/1201344/ > these two patches will likely conflict. I'd rather have them both in bpf tree. > What is the value for this patch in perf tree? > To fix the build on 32-bit arches, right? > But how urgent is it? Can you wait few days until this one and other > libbpf fixes > land via bpf/net trees? Ok, I'll add a note to the pull request report about where the perf build is clean in all containers because I added these two patches, but that they'll go via the bpf tree, as soon as that gets merged, the problem will go away. And I wasn't strictly defending that I should carry this in perf/core, just said I was, to fix something minor that I found while doing my usual testing, patch was posted, you got notified and got the patch, I'll remove it from perf/core now since you stated that it'll eventually land upstream. Thanks, - Arnaldo
