Andrii Nakryiko

> > > I see, maintainers of this software don't know how to maintain symbol versioning properly. Ok, so given nothing is broken, perhaps this conclusion wasn't 100% accurate. >...

> pass the instructions directly to the syscall and > program relocation and loading happens with libbpf are in diagreement. Which one it is? I think, if at all possible,...

> libbpf should do the loading, it's just a question of how we get there yeah, I was trying to understand if that's the plan, thanks! It makes sense to...

We generally recommend to use UAPI headers bundled with libbpf itself under https://github.com/libbpf/libbpf/tree/master/include/uapi/linux. Would that work for you? Also please see https://github.com/libbpf/libbpf#libbpf-and-general-bpf-usage-questions, thanks.

This wasn't intentional, if that's what you are implying. But it's also not as simple as just re-defining those BTF_KIND_xxx constants (we can't just re-define struct btf_enum64 due to conflicts...

This should be fixed by https://patchwork.kernel.org/project/netdevbpf/patch/[email protected]/. Once that lands upstream I'll sync this into Github and will cherry-pick as 1.0.1 version.

@tohojo can you please test https://github.com/libbpf/libbpf/tree/libbpf-v1.0.1 in your environment to make sure your original issue is fixed and nothing new cropped up? Thanks.

@tohojo thanks for checking!

Thanks! I'll take a closer look in next few days. My biggest beef with LGTM was inability to just dismiss bogus warnings. So if CodeQL allows that, that's a big...

sorry for the delay, I'm landing it. Please lend a hand in nearest future if something doesn't work with this. Thanks!