kprobes is focusing on probing just a single probe point, and it can probe
everywhere including function body. With this charactoristics, user can
made a callback logic which is specialized for a specific address.
typedef int (*kprobe_pre_handler_t) (struct kprobe *, struct pt_regs *);
On the other hand, fprobe focuses on the multiple function entry and exit.
That is just a wrapper of ftrace. So callbacks will need to check the
function IP and change their behavior according to the IP.
void (*entry_handler)(struct fprobe *fp, unsigned long entry_ip, struct pt_regs *regs);
void (*exit_handler)(struct fprobe *fp, unsigned long entry_ip, struct pt_regs *regs);
This is why the fprobe handler gets @entry_ip for the handlers.
However, from viewpoint of the higher level users, those may look same
because both interrupts the kernel execution and callback their program
like BPF. BPF can select collect program according to the instruction_pointer
of @regs in both case.
In that case, I think it is natual that the BPF layer hides those differences
from user, by abstracting those as a generic "kprobe" which means an idea of
the general kernel instrumentation.
Thank you,
--
Masami Hiramatsu <mhiramat@xxxxxxxxxx>
