On Mon, Nov 1, 2021 at 7:33 PM Alexei Starovoitov
<alexei.starovoitov@xxxxxxxxx> wrote:
>
> On Fri, Oct 29, 2021 at 09:59:32PM -0700, Andrii Nakryiko wrote:
> > -int bpf_prog_load(const char *file, enum bpf_prog_type type,
> > - struct bpf_object **pobj, int *prog_fd)
> > +COMPAT_VERSION(bpf_prog_load_deprecated, bpf_prog_load, LIBBPF_0.0.1)
> > +int bpf_prog_load_deprecated(const char *file, enum bpf_prog_type type,
> > + struct bpf_object **pobj, int *prog_fd)
> ..
> > diff --git a/tools/lib/bpf/libbpf.map b/tools/lib/bpf/libbpf.map
> > index 43580eb47740..b895861a13c0 100644
> > --- a/tools/lib/bpf/libbpf.map
> > +++ b/tools/lib/bpf/libbpf.map
> > @@ -395,6 +395,8 @@ LIBBPF_0.6.0 {
> > bpf_object__next_program;
> > bpf_object__prev_map;
> > bpf_object__prev_program;
> > + bpf_prog_load_deprecated;
> > + bpf_prog_load;
> > bpf_program__insn_cnt;
> > bpf_program__insns;
> > btf__add_btf;
>
> Is it really LIBBPF_0.0.1 ? or 0.6.0 ? which one is correct.
> Maybe I'm misreading what COMPAT macro will do.
I followed very closely what was done for xsk_umem__create. Original
bpf_prog_load was introduced in LIBBPF_0.0.1, so COMPAT_VERSION has to
use that version. And then a new bpf_prog_load is added in
LIBBPF_0.6.0, so DEFAULT_VERSION is referencing that one.
What this should mean in practice is that if someone specifically
requests bpf_prog_load@LIBBPF_0.0.1 (which should be everything that
was compiled with libbpf v0.0.1 through v0.5), they would use old
6-arg version of bpf_prog_load. Anything compiled starting from v0.6+
will use bpf_prog_load@LIBBPF_0.6.0. If anyone just references
bpf_prog_load (not sure how to do that with C, tbh), they will default
to bpf_prog_load@LIBBPF_0.6.0.
And then when someone compiles against libbpf v0.6+ and indeed uses
old bpf_prog_load w/ 6 args, they will be actually compiling against
bpf_prog_load_deprecated@LIBBPF_0.6.0 due to the ___libbpf_overload()
magic.
But this is certainly confusing, I've spent a bunch of time staring at
xsk_umem__create().
