tctracer: move maps to their own files

[rafaelroquetto]

This is a part of what should be a series or PRs that aim to tide up our ebpf code.

This one just moves the private tctracer maps to their own subdir.

[codecov]

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 67.16%. Comparing base (a2c0758) to head (7e5fc95).
Report is 1 commits behind head on main.

Additional details and impacted files

@@            Coverage Diff             @@
##             main    #1796      +/-   ##
==========================================
- Coverage   67.23%   67.16%   -0.08%     
==========================================
  Files         219      219              
  Lines       22605    22605              
==========================================
- Hits        15199    15183      -16     
- Misses       6634     6645      +11     
- Partials      772      777       +5     

Flag	Coverage Δ
integration-test	54.62% <ø> (-0.31%)	⬇️
k8s-integration-test	53.05% <ø> (-0.02%)	⬇️
oats-test	34.33% <ø> (+0.02%)	⬆️
unittests	43.47% <ø> (ø)

Flags with carried forward coverage won't be shown. Click here to find out more.

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
• 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

[mariomac]

Thanks for the reorganization!! For curiosity from a non-C guy: what's the reason to put all of them in different include files instead of moving them all together to a single "tctracer_maps.h" file?

[rafaelroquetto]

Thanks for the reorganization!! For curiosity from a non-C guy: what's the reason to put all of them in different include files instead of moving them all together to a single "tctracer_maps.h" file?

@mariomac normally in a non-eBPF realms that's exactly what I'd have done. But with eBPF (and in particular, ebpf2go), what happens is that the final .o file is scanned, and the .go bindings are generated, containing all maps included in that .o file, which will then be loaded "automagically" into the kernel by the .go bindings.

For shared maps (those shared across tracers and living in the toplevel ebpf/maps dir), having a single map per file allows us to include (and load) only those that were really being used by a given tracer. Before this refactor, a few maps ended up in tracers (and loaded, consuming resources) that were not using them.

For private maps, your approach would work, but I've opted to stick to the approach used for the shared maps for a few reasons:

1. consistency and less cognitive load when deciding where to place a new map
2. clarity (this also applies to shared maps): because ebpf maps are the conduits gluing different ebpf programs and the userspace together, I personally find it very helpful to be able to see what maps are being used in my particular code by gazing at the include list - so a bit more verbose, indeed, but also clearer IMHO.

[grcevski]

LGTM!