On Mon, Mar 14, 2022 at 4:50 PM Delyan Kratunov <delyank@xxxxxx> wrote: > > On Fri, 2022-03-11 at 15:40 -0800, Andrii Nakryiko wrote: > > > > we shouldn't need or use name for subskeleton (in real life you won't > > know the name of the final bpf_object) > > Let's have this discussion in the bpftool email thread. Happy to remove the name > in the Makefile and fall back on the filename though. > It's fine, keep it, you explained why we need it. > > > > > > $(TRUNNER_BPF_LSKELS): %.lskel.h: %.o $(BPFTOOL) | $(TRUNNER_OUTPUT) > > > $$(call msg,GEN-SKEL,$(TRUNNER_BINARY),$$@) > > > @@ -421,6 +428,7 @@ $(TRUNNER_BPF_SKELS_LINKED): $(TRUNNER_BPF_OBJS) $(BPFTOOL) | $(TRUNNER_OUTPUT) > > > $(Q)diff $$(@:.skel.h=.linked2.o) $$(@:.skel.h=.linked3.o) > > > $$(call msg,GEN-SKEL,$(TRUNNER_BINARY),$$@) > > > $(Q)$$(BPFTOOL) gen skeleton $$(@:.skel.h=.linked3.o) name $$(notdir $$(@:.skel.h=)) > $$@ > > > + $(Q)$$(BPFTOOL) gen subskeleton $$(@:.skel.h=.linked3.o) name $$(notdir $$(@:.skel.h=)) > $$(@:.skel.h=.subskel.h) > > > > probably don't need subskel for LSKELS (and it just adds race when we > > generate both skeleton and light skeleton for the same object file) > > We're not generating subskels for LSKELS, that's just confusing diff output. > This is under the $(TRUNNER_BPF_SKELS_LINKED) outputs. indeed confusing, never mind then > > > > > can you please add CONFIG_BPF_SYSCALL here as well, to check that > > externs are properly "merged" and found, even if they overlap between > > library and app BPF code > > Sure. > > > > > libbpf supports .data.my_custom_name and .rodata.my_custom_whatever, > > let's have a variable to test this also works? > > Sure. > > > > > let's move this into progs/test_subskeleton.c instead. It will > > simulate a bit more complicated scenario, where library expects > > application to define and provide a map, but the library itself > > doesn't define it. It should work just fine right now (I think), but > > just in case let's double check that having only "extern map" in the > > library works. > > This fails to even open in bpftool: > > libbpf: map 'map2': unsupported map linkage extern. > Error: failed to open BPF object file: Operation not supported > > If we think this is valuable enough to support, let's tackle it separately after > the bulk of this functionality is merged? yep, totally. It's not super critical to support, but seems like a useful use case for library to be able to access some pre-agreed map in the final BPF app > > > -- Delyan
