Libbpf has bpf_helpers.h which is mostly platform-agnostic, and
bpf_helper_defs.h which is platform-specific but is included
by bpf_helpers.h. Until libbpf is made more platform-agnostic
(issue #351), the workaround is to have a separate pair of files.
Our bpf_helpers.h and our own bpf_helper_defs.h, both of which
would ideally be merged into libbpf's in the future.
Platform-specific defines are in ebpf_struct.h, though that
name may need to change later on. Linux uses "linux/bpf.h"
(e.g., as used in the https://docs.cilium.io/en/v1.8/bpf/ and
https://developers.redhat.com/blog/2021/04/01/get-started-with-xdp
articles) or "vmlinux.h" (e.g., as used in the
https://ruderich.org/simon/notes/xdp-minimal-example article),
and these filenames are hard coded in eBPF programs. In the future,
we should probably settle on a cross-platform name and use include
paths to distinguish them, as opposed to requiring ifdefs in eBPF
programs. However, all of that is part of issue 351 and not this
issue.
Also removed obsolete/unused "repro.c" from tests/samples
Fixes#426
Signed-off-by: Dave Thaler <dthaler@microsoft.com>
Co-authored-by: Alan Jowett <alanjo@microsoft.com>
* Add map-in-map type checking
This PR enforces that all inner maps must be of the same type
as the inner map template used for verification. Other fields
might need to match too, and if so those will be updated in
a subsequent PR once it is confirmed which fields must match.
A few pieces of this PR related to map_id are prerequisites
for issue #396 which will add IDs for programs, maps, and links.
Finally, there are multiple definitions of bpf_map, since the
version used to write eBPF programs is different from what is
stored in memory (which uses map IDs) so to avoid confusion in
code and allow the compiler to do type checking to catch some
bugs, this splits ebpf_map_definition_t into two, one for
in_memory and one for in_file (meaning in an eBPF program).
This will also allow the future PR for issue 396 to be more
understandable, but also aids clarity in some parts of this PR.
Signed-off-by: Dave Thaler <dthaler@microsoft.com>
Shankar Seal
Dave Thaler