On Tue, Sep 20, 2022 at 1:55 PM Andrii Nakryiko
<andrii.nakryiko@xxxxxxxxx> wrote:
>
> On Sun, Sep 11, 2022 at 3:31 PM Alexei Starovoitov
> <alexei.starovoitov@xxxxxxxxx> wrote:
> >
> > On Fri, Sep 09, 2022 at 05:21:52PM -0700, Andrii Nakryiko wrote:
> > > > >
> > > > > Well, I didn't propose to use suffixes. Currently user can define
> > > > > SEC(".data.my_custom_use_case").
> > > >
> > > > ... and libbpf will mmap such maps and will expose them in skeleton.
> > > > My point that it's an existing bug.
> > >
> > > hm... it's not a bug, it's a desired feature. I wanted
> > >
> > > int my_var SEC(".data.mine");
> > >
> > > to be just like .data but in a separate map. So no bug here.
> >
>
> Not to bury the actual proposal at the end of this email, I'll put it
> here upfront, as I think it's a better compromise.
>
> Given the initial problem was that libbpf creates an mmap-able array
> for data sections, how about we make libbpf smarter.
>
> The rule is simple and unambiguous: if ELF data section doesn't
> contain any global variable, libbpf will not add MMAPABLE flag? I.e.,
> if it's special compiler sections which have no variables, or if it's
> user data section that only has static variables (which explicitly are
> not to be exposed in BPF skeleton), libbpf just creates non-mmapable
> array and we don't expose such sections as skeleton structs.
>
> User can still enforce MMAPABLE flag with explicit
> bpf_map__set_map_flags(), if necessary, so if libbpf's default
> behavior isn't sufficient and user intended mmapable array, they can
> still get this working.
>
> That would cover your use case and won't require any new naming
> conventions. WDYT?
>
>
To close the loop, I went ahead and implemented this proposal in code.
See [0]. I think it should be a good first step and should unblock all
the linked list and rbtree_node work. Please give it a try.
[0] https://patchwork.kernel.org/project/netdevbpf/list/?series=686066&state=*
[...]
