You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
cilium/ebpf is pure Go. No CGo required, no need to install libbpf on developer machines etc.. It will also make enabling the linter on all packages chore: Enable linter for libbpf/gpu tags #1423 much easier
We can use bpf2go to compile the eBPF bytecode instead of using clang directly. This removes boilerplate + Makefile and has the added benefit that the bytecode is embedded directly into the built binary, removing the need for fix(bpfassets): Fix object file lookup #1419 and simplifying packaging.
Removes the need for Dockerfile.builder everywhere except for RPMs. This should make things like updating the Go version much simpler without causing CI instability.
Automatically keeping the keplerProcessMetricsT struct in sync between userland and the kernel
I've tested this and I have a feature branch ready to go as soon as #1413 has landed, which is a pre-requisite to doing this cleanly.
The text was updated successfully, but these errors were encountered:
What would you like to be added?
Replace the dependency on libbpfgo with cilium/ebpf.
Why is this needed?
This has a number of benefits:
cilium/ebpf
is pure Go. No CGo required, no need to install libbpf on developer machines etc.. It will also make enabling the linter on all packages chore: Enable linter for libbpf/gpu tags #1423 much easierbpf2go
to compile the eBPF bytecode instead of usingclang
directly. This removes boilerplate + Makefile and has the added benefit that the bytecode is embedded directly into the built binary, removing the need for fix(bpfassets): Fix object file lookup #1419 and simplifying packaging.Dockerfile.builder
everywhere except for RPMs. This should make things like updating the Go version much simpler without causing CI instability.keplerProcessMetricsT
struct in sync between userland and the kernelI've tested this and I have a feature branch ready to go as soon as #1413 has landed, which is a pre-requisite to doing this cleanly.
The text was updated successfully, but these errors were encountered: