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.
