On Thu, 22 Oct 2020 16:11:54 +0200 Jiri Olsa <jolsa@xxxxxxxxxx> wrote: > I understand direct calls as a way that bpf trampolines and ftrace can > co-exist together - ebpf trampolines need that functionality of accessing > parameters of a function as if it was called directly and at the same > point we need to be able attach to any function and to as many functions > as we want in a fast way I was sold that bpf needed a quick and fast way to get the arguments of a function, as the only way to do that with ftrace is to save all registers, which, I was told was too much overhead, as if you only care about arguments, there's much less that is needed to save. Direct calls wasn't added so that bpf and ftrace could co-exist, it was that for certain cases, bpf wanted a faster way to access arguments, because it still worked with ftrace, but the saving of regs was too strenuous. > > the bpftrace example above did not use arguments for simplicity, but they > could have been there ... I think we could detect arguments presence in > ebpf programs and use ftrace_ops directly in case they are not needed What I don't see, is how one would need to access arguments for a lot of calls directly? The direct trampoline was for "one-offs", because for every function that has a direct trampoline, it prevents kretprobes and function graph tracer from accessing it. Before I allow a "batch" direct caller, I need it to not break function graph tracing. If we are going to have a way to get parameters for multiple functions, I would then like to have that be directly part of the ftrace infrastructure. That is, allow more than just bpf to have access to this. If it's going to be generic, then let's have it work for all function trace users and not just bpf. I'd like to see how batch functions will work. I guess I need to start looking at the bpf trampoline, to see if we can modify the ftrace trampoline to have a quick access to parameters. It would be much more beneficial to update the existing generic function tracer to have access to function parameters that all users could benefit from, than to tweak a single use case into giving this feature to a single user. -- Steve
