On Thu, 3 Feb 2022 18:12:11 -0800 Alexei Starovoitov <alexei.starovoitov@xxxxxxxxx> wrote: > On Thu, Feb 3, 2022 at 6:07 PM Masami Hiramatsu <mhiramat@xxxxxxxxxx> wrote: > > > > On Thu, 3 Feb 2022 17:34:54 -0800 > > Alexei Starovoitov <alexei.starovoitov@xxxxxxxxx> wrote: > > > > > On Thu, Feb 3, 2022 at 4:46 PM Masami Hiramatsu <mhiramat@xxxxxxxxxx> wrote: > > > > > > > > I thought What Alexei pointed was that don't expose the FPROBE name > > > > to user space. If so, I agree with that. We can continue to use > > > > KPROBE for user space. Using fprobe is just for kernel implementation. > > > > > > Clearly that intent is not working. > > > > Thanks for confirmation :-) > > > > > The "fprobe" name is already leaking outside of the kernel internals. > > > The module interface is being proposed. > > > > Yes, but that is only for making the example module. > > It is easy for me to enclose it inside kernel. I'm preparing KUnit > > selftest code for next version. After integrated that, we don't need > > that example module anymore. > > > > > You'd need to document it, etc. > > > > Yes, I've added a document of the APIs for the series. :-) > > > > > I think it's only causing confusion to users. > > > The new name serves no additional purpose other than > > > being new and unheard of. > > > fprobe is kprobe on ftrace. That's it. > > > > No, fprobe is NOT kprobe on ftrace, kprobe on ftrace is already implemented > > transparently. > > Not true. > fprobe is nothing but _explicit_ kprobe on ftrace. > There was an implicit optimization for kprobe when ftrace > could be used. > All this new interface is doing is making it explicit. > So a new name is not warranted here. > > > from that viewpoint, fprobe and kprobe interface are similar but different. > > What is the difference? > I don't see it.
