Subject: Re: [PATCH bpf-next 2/6] libbpf: move bpf_helpers.h, bpf_endian.h into libbpf

From: Toke Høiland-Jørgensen <[email-masked]>
Date: Wed, 02 Oct 2019 09:25:21 +0200

Andrii Nakryiko <[email-masked]> writes:

> On Tue, Oct 1, 2019 at 12:18 PM John Fastabend <[email-masked]> 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.

This was the thread; the context was libbpf support in iproute2:
https://lore.kernel.org/netdev/[email-masked]/

Basically, we agreed that rather than adding more fields to bpf_map_def
in libbpf itself, we'd support BTF definitions natively, and provide
applications the right callbacks to support custom formats as they see
fit.

-Toke