On Thu, Oct 22, 2020 at 2:03 AM Jiri Olsa <jolsa@xxxxxxxxxx> wrote: > > Adding trampoline batch attach support so it's possible to use > batch mode to load tracing programs. > > Adding trampoline_attach_batch bool to struct bpf_object_open_opts. > When set to true the bpf_object__attach_skeleton will try to load > all tracing programs via batch mode. > > Signed-off-by: Jiri Olsa <jolsa@xxxxxxxxxx> > --- Assuming we go with the current kernel API for batch-attach, why can't libbpf just detect kernel support for it and just use it always, without requiring users to opt into anything? But I'm also confused a bit how this is supposed to be used with BPF skeleton. You use case described in a cover letter (bpftrace glob attach, right?) would have a single BPF program attached to many different functions. While here you are trying to collect different programs and attach each one to its respective kernel function. Do you expect users to have hundreds of BPF programs in their skeletons? If not, I don't really see why adding this complexity. What am I missing? Now it also seems weird to me for the kernel API to allow attaching many-to-many BPF programs-to-attach points. One BPF program-to-many attach points seems like a more sane and common requirement, no? > tools/lib/bpf/bpf.c | 12 +++++++ > tools/lib/bpf/bpf.h | 1 + > tools/lib/bpf/libbpf.c | 76 +++++++++++++++++++++++++++++++++++++++- > tools/lib/bpf/libbpf.h | 5 ++- > tools/lib/bpf/libbpf.map | 1 + > 5 files changed, 93 insertions(+), 2 deletions(-) > [...]
