Steven wrote: > On Sun, 30 Aug 2026 19:07:43 +0800 (CST) > <[email protected]> wrote: > > > Hi Steven and Masami, > > > > This series adds two comm-based task filters for the function and > > function_graph tracers: > > > > set_ftrace_comm > > set_ftrace_notrace_comm > > I'd like to avoid adding more files like this. If anything, I would love to > add triggers to the function tracers.
Agreed. Adding two more tracefs files may not be the best interface. Together with the points raised in the earlier discussion with Masami, I also think a trigger-based interface would be a cleaner direction. > > > > Function tracing currently supports selecting tasks by PID. This makes > > it difficult to configure tracing before a service starts, because it > > does not have a PID yet. It is also inconvenient to keep tracing the > > same service across restarts, as its PID may change. This use case was > > suggested by Xuxin, a KSM reviewer. > > I've always recommended a simple wrapper script for applications: > > echo '#! /bin/bash > echo $$ > /sys/kernel/tracing/set_ftrace_pid > echo $$ > /sys/kernel/tracing/set_event_pid > exec "$@"' > trace-me.sh > > chmod +x trace-me.sh > > ./trace-me.sh command to be traced > > The above will do what you want. > Yes, this works well when we have control over how the application is launched. Thanks for the example! > But if we really do want to add more filters to function tracing, then > adding triggers to it would be the way to go. Understood. To make sure I understand the proposed direction, here is a conceptual example of what the interface might look like: echo 'ftrace_pid_add if newcomm == "foo"' > \ events/task/task_rename/trigger When a task changes its comm to foo, the trigger would add the PID from the task_rename event to the function tracer's PID filter. The function and function_graph tracers would then trace that task using the existing PID-filtering mechanism. We may also need a corresponding ftrace_pid_remove trigger command to remove the PID associated with the triggering event from the function tracer's PID list. The command names above are only illustrative. Is this roughly the kind of trigger interface you had in mind? If so, we will investigate extending the trigger infrastructure in this direction instead of adding the comm-filter files. -- With Best Regards, Shengming
