Re: [RFC 00/13] kprobe/bpf: Add support to attach multiple kprobes

[Masami Hiramatsu]

On Thu, 6 Jan 2022 09:40:17 -0800
Alexei Starovoitov <alexei.starovoitov@xxxxxxxxx> wrote:

> On Thu, Jan 6, 2022 at 5:59 AM Masami Hiramatsu <mhiramat@xxxxxxxxxx> wrote:
> >
> > That seems to bind your mind. The program type is just a programing
> > 'model' of the bpf. You can choose the best implementation to provide
> > equal functionality. 'kprobe' in bpf is just a name that you call some
> > instrumentations which can probe kernel code.
> 
> No. We're not going to call it "fprobe" or any other name.
> From bpf user's pov it's going to be "multi attach kprobe",
> because this is how everyone got to know kprobes.
> The 99% usage is at the beginning of the funcs.
> When users say "kprobe" they don't care how kernel attaches it.
> The func entry limitation for "multi attach kprobe" is a no-brainer.

Agreed. I think I might mislead you. From the bpf user pov, it always be
shown as 'multi attached kprobes (but only for the function entry)'
the 'fprobe' is kernel internal API name.

> And we need both "multi attach kprobe" and "multi attach kretprobe"
> at the same time. It's no go to implement one first and the other
> some time later.

You can provide the interface to user space, but the kernel implementation
is optimized step by step. We can start it with using real multiple
kretprobes, and then, switch to 'fprobe' after integrating fgraph
callback. :)

Thank you,

-- 
Masami Hiramatsu <mhiramat@xxxxxxxxxx>