On Thu, Nov 05, 2020 at 08:25:12AM -0700, David Ahern wrote: > > Sorry, when trying to rename the functions. I just found another issue. > > Even we fix the conflicts right now. What if libbpf add new functions > > and we got another conflict in future? There are too much bpf functions > > in bpf_legacy.c which would have more risks for naming conflicts.. > > > > With bpf_libbpf.c, there are less functions and has less risk for naming > > conflicts. So I think it maybe better to not include libbpf.h in bpf_legacy.c. > > What do you think? > > > > > > Is there a way to sort the code such that bpf_legacy.c is not used when > libbpf is enabled and bpf_libbpf.c is not compiled when libbpf is disabled. > That what the current code did. In lib/Makefile we only compile bpf_libbpf.o when libbpf enabled. ifeq ($(HAVE_LIBBPF),y) UTILOBJ += bpf_libbpf.o endif But bpf code in ipvrf.c is special as it calls both legacy code an libbpf code. If we put it in bpf_legacy.c, then bpf_legacy.c will be corrupt by libbpf.h. If we put it in bpf_libbpf.c, then we can't build without bpf_libbpf.o when libbpf disable. I haven't figured out a better solution. Thanks Hangbin
