Re: [PATCH 15/19] libbpf: Add support to link multi func tracing program

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Thu, Jun 10, 2021 at 10:05:39AM -0700, Andrii Nakryiko wrote:

SNIP

> > > > +static struct bpf_link *bpf_program__attach_multi(struct bpf_program *prog)
> > > > +{
> > > > +       char *pattern = prog->sec_name + prog->sec_def->len;
> > > > +       DECLARE_LIBBPF_OPTS(bpf_link_create_opts, opts);
> > > > +       enum bpf_attach_type attach_type;
> > > > +       int prog_fd, link_fd, cnt, err;
> > > > +       struct bpf_link *link = NULL;
> > > > +       __s32 *ids = NULL;
> > > > +
> > > > +       prog_fd = bpf_program__fd(prog);
> > > > +       if (prog_fd < 0) {
> > > > +               pr_warn("prog '%s': can't attach before loaded\n", prog->name);
> > > > +               return ERR_PTR(-EINVAL);
> > > > +       }
> > > > +
> > > > +       err = bpf_object__load_vmlinux_btf(prog->obj, true);
> > > > +       if (err)
> > > > +               return ERR_PTR(err);
> > > > +
> > > > +       cnt = btf__find_by_pattern_kind(prog->obj->btf_vmlinux, pattern,
> > > > +                                       BTF_KIND_FUNC, &ids);
> > >
> > > I wonder if it would be better to just support a simplified glob
> > > patterns like "prefix*", "*suffix", "exactmatch", and "*substring*"?
> > > That should be sufficient for majority of cases. For the cases where
> > > user needs something more nuanced, they can just construct BTF ID list
> > > with custom code and do manual attach.
> >
> > as I wrote earlier the function is just for the purpose of the test,
> > and we can always do the manual attach
> >
> > I don't mind adding that simplified matching you described
> 
> I use that in retsnoop and that seems to be simple but flexible enough
> for all the purposes, so far. It matches typical file globbing rules
> (with extra limitations, of course), so it's also intuitive.
> 
> But I still am not sure about making it a public API, because in a lot
> of cases you'll want a list of patterns (both allowing and denying
> different patterns), so it should be generalized to something like
> 
> btf__find_by_glob_kind(btf, allow_patterns, deny_patterns, ids)
> 
> which gets pretty unwieldy. I'd start with telling users to just
> iterate BTF on their own and apply whatever custom filtering they
> need. For simple cases libbpf will just initially support a simple and
> single glob filter declaratively (e.g, SEC("fentry.multi/bpf_*")).

ok, I'll scan retsnoop and see what I can steal ;-)

jirka




[Index of Archives]     [Linux Samsung SoC]     [Linux Rockchip SoC]     [Linux Actions SoC]     [Linux for Synopsys ARC Processors]     [Linux NFS]     [Linux NILFS]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]


  Powered by Linux