On Fri, May 15, 2020 at 2:19 PM <[email protected]> wrote: > > <[email protected]>,Stephane Eranian <[email protected]> > From: Arnaldo Carvalho de Melo <[email protected]> > Message-ID: <[email protected]> > > > > On May 15, 2020 4:42:46 PM GMT-03:00, Andrii Nakryiko > <[email protected]> wrote: > >On Fri, May 15, 2020 at 10:01 AM Arnaldo Carvalho de Melo > ><[email protected]> wrote: > >> > >> Em Fri, May 15, 2020 at 09:50:00AM -0700, Ian Rogers escreveu: > >> > Perf's expr code currently builds an array of strings then removes > >> > duplicates. The array is larger than necessary and has recently > >been > >> > increased in size. When this was done it was commented that a > >hashmap > >> > would be preferable. > >> > > >> > libbpf has a hashmap but libbpf isn't currently required to build > >> > perf. To satisfy various concerns this change copies libbpf's > >hashmap > >> > into tools/perf/util, it then adds a check in perf that the two are > >in > >> > sync. > >> > > >> > Andrii's patch to hashmap from bpf-next is brought into this set to > >> > fix issues with hashmap__clear. > >> > > >> > Two minor changes to libbpf's hashmap are made that remove an > >unused > >> > dependency and fix a compiler warning. > >> > >> Andrii/Alexei/Daniel, what do you think about me merging these fixes > >in my > >> perf-tools-next branch? > > > >I'm ok with the idea, but it's up to maintainers to coordinate this :) > > Good to know, do I'll take all patches except the ones touching libppf, will > just make sure the copy is done with the patches applied. > > At some point they'll land in libbpf and the warning from check_headers.sh > will be resolved.
So tools/perf/util's hashmap will be ahead of libbpf's, as without the fixes the perf build is broken by Werror. This will cause check_headers to warn in perf builds, which would usually mean our header was older than the source one, but in this case it means the opposite, we're waiting for the libbpf patches to merge. Aside from some interim warnings everything will resolve itself and Arnaldo avoids landing patches in libbpf that can interfere with bpf-next. It takes some getting your head around but sounds good to me :-) I think the only workable alternatives would be to explore having a single version of the code in some kind of shared libhashmap or to implement another hashmap in libapi. I'd like to get the rest of this work unblocked and so it'd be nice to land this and we can always refactor later - I like Arnaldo's plan. Can a bpf maintainer make sure the hashmap changes get pulled into bpf-next? Thanks! Ian > Thanks, > > - Arnaldo > > -- > Sent from my Android device with K-9 Mail. Please excuse my brevity.
