Re: Include file bpf.h in directory /usr/lib/include/perf/bpf/bpf.h

[Arnaldo Carvalho de Melo <acme@kernel.org>]

Em Tue, Jul 24, 2018 at 12:49:43PM +0200, Stefan Liebler escreveu:
> In each case, the introduction of the subdirectory /usr/lib/include leads to
> the regression that one can't build the glibc RPM for s390 anymore as gcc
> can't find headers like stdbool.h.
 
> Should bpf.h be moved to /usr/lib/perf/include/bpf/bpf.h?

Thanks for the report, yes, I agree with your analysis, breaking the
assumptions of existing setups like that is not good, can you send a
patch, including this analysis so that this gets documented in the
project's git changeset history?

I wonder if we even shouldn't go one extra step and have it in:

/usr/lib/perf/bpf/include/bpf/bpf.h?

That extra /bpf/ is to make it sure that everything below
/usr/lib/perf/bpf/ is to be used in generating eBPF objects to be loaded
via sys_bpf(), of which the "include/bpf" subdir and bpf.h are for basic
BPF aspects such as the definition of maps, etc, while include/fmt/
(below /usr/lib/perf/bpf/) could be C inline functions to be used in .c
files to generate eBPF ELF objects, and other function "libraries" could
live in different directories in this hierarchy.

One can think about /usr/lib/perf/something-else-that-requires-c-headers/
like if we decide to create shared objects to process tracepoint events
obtained from the kernel in a pretty format by just using the tracefs
metadata, where we would transform a .c file into something other than
a eBPF ELF file.

But yeah, to fix the problem you described we have to have it all under
/usr/lib/perf/

- Arnaldo