John Fastabend <john.fastabend@xxxxxxxxx> writes: > Toke Høiland-Jørgensen wrote: >> Alexei Starovoitov <alexei.starovoitov@xxxxxxxxx> writes: >> >> > On Wed, Oct 09, 2019 at 10:03:43AM +0200, Toke Høiland-Jørgensen wrote: >> >> Alexei Starovoitov <alexei.starovoitov@xxxxxxxxx> writes: >> >> >> >> > Please implement proper indirect calls and jumps. >> >> >> >> I am still not convinced this will actually solve our problem; but OK, I >> >> can give it a shot. >> > >> > If you're not convinced let's talk about it first. >> > >> > Indirect calls is a building block for debugpoints. >> > Let's not call them tracepoints, because Linus banned any discusion >> > that includes that name. >> > The debugpoints is a way for BPF program to insert points in its >> > code to let external facility to do tracing and debugging. >> > >> > void (*debugpoint1)(struct xdp_buff *, int code); >> > void (*debugpoint2)(struct xdp_buff *); >> > void (*debugpoint3)(int len); > > I was considering some basic static linking from libbpf side. Something > like, > > bpf_object__link_programs(struct bpf_object *obj1, struct bpf_object *obj2); > > This way you could just 'link' in debugpoint{1,2,3} from libbpf before > loading? This would be useful on my side for adding/removing features > and handling different kernel versions. So more generally useful IMO. So that will end up with a single monolithic BPF program being loaded (from the kernel PoV), right? That won't do; we want to be able to go back to the component programs, and manipulate them as separate kernel objects. -Toke