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>
