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
