On Wed, Jul 12, 2023 at 8:05 AM Alexei Starovoitov <alexei.starovoitov@xxxxxxxxx> wrote: > > On Tue, Jul 11, 2023 at 10:42 PM Andrii Nakryiko > <andrii.nakryiko@xxxxxxxxx> wrote: > > > > On Tue, Jul 11, 2023 at 6:05 PM Jackie Liu <liu.yun@xxxxxxxxx> wrote: > > > > > > From: Jackie Liu <liuyun01@xxxxxxxxxx> > > > > > > Now multi kprobe uses glob_match for function matching, it's not enough, > > > and sometimes we need more powerful regular expressions to support fuzzy > > > matching, and now provides a use_regex in bpf_kprobe_multi_opts to support > > > POSIX regular expressions. > > > > > > This is useful, similar to `funccount.py -r '^vfs.*'` in BCC, and can also > > > be implemented with libbpf. > > > > > > Signed-off-by: Jackie Liu <liuyun01@xxxxxxxxxx> > > > --- > > > tools/lib/bpf/libbpf.c | 52 ++++++++++++++++++++++++++++++++++++++---- > > > tools/lib/bpf/libbpf.h | 4 +++- > > > 2 files changed, 51 insertions(+), 5 deletions(-) > > > > > > > Let's hold off on adding regex support assumptions into libbpf API. > > Globs are pretty flexible already for most cases, and for some more > > advanced use cases users can provide an exact list of function names > > through opts argument. > > > > We can revisit this decision down the road, but right now it seems > > premature to sign up for such relatively heavy-weight API dependency. > > regexec() is part of glibc and we cannot link it statically, > so no change in libbpf.a/so size. right, I wasn't worried about the code size increase of libbpf itself > Are you worried about ulibc-like environment? This is one part. musl, uclibc, and other alternative implementations of glibc: do they support same functionality with all the same options and syntax. I'd feel more comfortable if we understood well all the implications of relying on this regex API: which glibc versions support it, same for musl. Are there any extra library dependencies that we might need to add (like -lm for some math functions). I'm not very familiar also with what regex flavor is implemented by POSIX regex, is it the commonly-expected Perl-compatible one, or something else? Also, we should have a good story on how this regex syntax is supported in SEC() definitions for both kprobe.multi and uprobe.multi. Stuff like this. But also, looking at bpftrace, I don't think it supports regex-based probe matching (e.g., I tried 'kprobe:.*sys_bpf' and it matched nothing; maybe there is some other syntax, but my Google-fu failed me). So assuming I didn't miss anything obvious with bpftrace, the fact that it's been around for so long with so many users and lack of regex doesn't seem to be the problem, I'm just not convinced we want to add regex to libbpf. At least not yet. Meanwhile, users can do regex-based symbol resolution on their own and just provide resolved function names to bpf_program__attach_kprobe_multi(), so lack of regex is not a blocker for anything. So that was my thought process and some reasons for hesitation.
