Andrii Nakryiko wrote:
> On Tue, Oct 1, 2019 at 12:18 PM John Fastabend <john.fastabend@xxxxxxxxx> wrote:
> >
> > Toke Høiland-Jørgensen wrote:
> > >
> > > > +struct bpf_map_def {
> > > > + unsigned int type;
> > > > + unsigned int key_size;
> > > > + unsigned int value_size;
> > > > + unsigned int max_entries;
> > > > + unsigned int map_flags;
> > > > + unsigned int inner_map_idx;
> > > > + unsigned int numa_node;
> > > > +};
> > >
> > > Didn't we agree on no new bpf_map_def ABI in libbpf, and that all
> > > additions should be BTF-based?
> > >
> > > -Toke
> > >
> >
> > We use libbpf on pre BTF kernels so in this case I think it makes
> > sense to add these fields. Having inner_map_idx there should allow
> > us to remove some other things we have sitting around.
>
> We had a discussion about supporting non-BTF and non-standard BPF map
> definition before and it's still on my TODO list to go and do a proof
> of concept how that can look like and what libbpf changes we need to
> make. Right now libbpf doesn't support those new fields anyway, so we
> shouldn't add them to public API.
I'm carrying around a patch for perf_event_open_probe() to get it working
without BTF I'll send that out today/tomorrow. It seems enough to get
all the basic prog load, maps reused/pinned, etc at least for my use
case.
>
> >
> > .John
