On 11/5/20 12:51 AM, Hangbin Liu wrote: > On Wed, Nov 04, 2020 at 07:33:40PM -0700, David Ahern wrote: >> On 11/4/20 1:22 AM, Hangbin Liu wrote: >>> If we move this #ifdef HAVE_LIBBPF to bpf_legacy.c, we need to rename >>> them all. With current patch, we limit all the legacy functions in >>> bpf_legacy >>> and doesn't mix them with libbpf.h. What do you think? >> >> Let's rename conflicts with a prefix -- like legacy. In fact, those >> iproute2_ functions names could use the legacy_ prefix as well. >> > > 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.
