Em Thu, Jan 21, 2021 at 12:02:53PM -0800, Andrii Nakryiko escreveu: > On Thu, Jan 21, 2021 at 5:29 AM Arnaldo Carvalho de Melo > <arnaldo.melo@xxxxxxxxx> wrote: > > > > Em Mon, Jan 04, 2021 at 10:17:36PM +0000, Luca Boccassi escreveu: > > > On Mon, 2021-01-04 at 12:23 -0800, Andrii Nakryiko wrote: > > > > On Sun, Jan 3, 2021 at 1:30 PM Luca Boccassi <bluca@xxxxxxxxxx> > > > > > > > #include "dutil.h" > > > > > > > +#ifdef LIBBPF_FOUND > > > > > > > +#include <bpf/libbpf.h> > > > > > > > +#else > > > > > > > #include "lib/bpf/src/libbpf.h" > > > > > > > +#endif > > > > > > > > this is horrible, are you sure there is no way to make > > > > > > <bpf/libbpf.h> > > > > > > work for both cases? > > > > > > > It really is, but unfortunately I don't see other ways that are > > > > > not just as horrible. Suggestions welcome. The only thing I can > > > > > think of, is if libbpf used the same directory hierarchy in-tree > > > > > as it does in the installed tree. Ie: move those headers from > > > > > libbpf/src/foo.h to libbpf/include/bpf/foo.h. Then we would just > > > > > have the - Ilib/bpf/include in CPPFLAGS for the embedded build > > > > > defined in the CMake files, and the sources would only use the > > > > > "system" includes everywhere, without ifdeffery. > > > > > > > Given you maintain libbpf, would that be something you'd accept? > > > > > It's quite a common pattern for libraries to store their public > > > > > headers in a separate directory in the git tree, after all. > > > > > > It's quite risky, as there are plenty of (sometimes private) > > > > integrations that assume such a layout of libbpf, so we'll be > > > > breaking them badly. Makefile-based projects do `make > > > > install_headers` to put *only exported* headers into the desired > > > > location. I'm not sure what's the best way to achieve the same with > > > > Cmake, though. > > > > > > One quick and easy hack would be to put a symlink lib/include/bpf -> > > > > lib/bpf/src into pahole repo. And add -Ilib/include to let compiler > > > > handle <bpf/*.h> properly. > > > > > Sure, that works for me if it's acceptable as a solution. Sent v3 that > > > implements it. Thanks for the suggestion. > > > > Andrii, can I have your Reviewed-by or Acked-by for v3? > > Well, I still think it's not good and not necessary for pahole. pahole > doesn't run under root. It's not a networking application open to the > world either. So I don't buy security arguments in this case at all. > So no, feel free to push this, but without my ack. > > > > > I have it in my local repo and will push publicly later today after I > > perform tests. > > While on the subject, do you have plans to release 1.20 any time soon? > I'm holding off until 1.20 is available to sync it internally to be > used for our kernels. Would be nice to get this off my head :) I planed to do it as quick release, but then holidays and my vacation got in the way, now there are some issues to solve, but I think I should release a version and then get back to those DWARF5 and 32-bit issues :-\ - Arnaldo
