On Mon, 2024-07-08 at 10:15 -0700, Andrii Nakryiko wrote: [...] > > static inline int > > profiler_bpf__create_skeleton(struct profiler_bpf *obj) > > { > > /* ... */ > > > > map = (struct bpf_map_skeleton *)((char *)s->maps + 0 * s->map_skel_sz); > > map->name = "events"; > > map->map = &obj->maps.events; > > > > /* ... 4 more like this ... */ > > > > /* ... */ > > > > s->progs[0].name = "fentry_XXX"; > > s->progs[0].prog = &obj->progs.fentry_XXX; > > s->progs[0].link = &obj->links.fentry_XXX; > > > > s->progs[1].name = "fexit_XXX"; > > s->progs[1].prog = &obj->progs.fexit_XXX; > > s->progs[1].link = &obj->links.fexit_XXX; > > > > /* ... */ > > } > > > > Do we need to handle 'progs' array access in a same way as maps? > > Given bpf_prog_skeleton has never been extended yet (and maybe never > will be), I chose not to uglify this unnecessarily. My thinking/hope > is that by the time we get to extending prog_skeleton struct, all > actively used libbpf versions will be patched up and will handle this > correctly without the hacks we have to do for map_skeleton. Understood, fair enough. [...]