Re: [PATCH bpf-next 3/4] libbpf: add subskeleton scaffolding

[Delyan Kratunov <delyank@fb.com>]

On Wed, 2022-03-02 at 20:34 -0800, Andrii Nakryiko wrote:
> > 
> 
> forgot to mention, this patch logically probably should go before
> bpftool changes: 1) define types and APIs in libbpf, and only then 2)
> "use" those in bpftool

Sure.

> > > 
> > > +struct bpf_sym_skeleton {
> > 
> > I tried to get used to this "sym" terminology for a bit, but it still
> > feels off. From user's perspective all this are variables. Any
> > objections to use "var" terminology?

"var" has a specific meaning in btf and I didn't want to make bpf_var_skeleton
look related to btf_var for example. Given the extern usage that libs require, I
figured "sym" would make sense to the user. 

If you don't think the confusion with btf_var is significant, I can rename it -
this is all used by generated code anyway.

> > 
> > > +       const char *name;
> > > +       const char *section;
> > 
> > what if we store a pointer to struct bpf_map * instead, that way we
> > won't need to search, we'll just have a pointer ready

We'd have to search *somewhere*. I'd rather have the search inside libbpf than
inside the generated code. Besides, finding the right bpf_map from within the
subskeleton is pretty annoying - you'll have to do suffix searches on the
bpf_map names in the passed-in bpf_object and codegening all that is unnecessary
when libbpf can look at real_name.

> 

Thanks,
Delyan