On Thu, Apr 4, 2024 at 11:27 AM Stephen Hemminger <stephen@xxxxxxxxxxxxxxxxxx> wrote: > > On Thu, 4 Apr 2024 11:16:32 -0700 > Yonghong Song <yonghong.song@xxxxxxxxx> wrote: > > > On 4/4/24 10:09 AM, Stephen Hemminger wrote: > > > I am fixing the use of TC BPF in DPDK to use libbpf and bpftool. > > > Luca recommended using vmlinux.h to address possible build and > > > CO:RE issues. But it won't work. > > > > > > There are missing pieces such as definitions of IPV6 next header > > > fields (in linux/ipv6.h) and TC actions. > > > > > > Without major hack surgery, not possible to use vmlinux.h instead. > > > Since vmlinux.h defines may things that overlap with other headers. > > > > > > Using: [...] > > This is a known issue as currently vmlinux.h does not support macros. > > There are some efforts by Edward Zingerman to support this but this has > > not done yet. At the same time, you could have a trivial header file > > like > > https://github.com/torvalds/linux/blob/master/tools/testing/selftests/bpf/progs/bpf_tracing_net.h > > to be used for bpf program and then your bpf program with vmlinux.h can > > have much easier CORE support. > > > That is an example of header surgery which I would rather avoid having to carry > as long term technical debt baggage. > What's your ultimate goal? As Yonghong said, vmlinux.h is not compatible with other headers. So you have to pick either using vmlinux.h as a base + adding missing #define's (because those are not recorded in types, so can't be put into vmlinux.h), or not use vmlinux.h, use linux UAPI/internal headers and then use explicit CO-RE helpers/attributes to make your application CO-RE-relocatable. It's not clear from your original email why exactly you wanted to switch to vmlinux.h in the first place.
