On Thu, 3 Jul 2025 09:57:37 -0700
Linus Torvalds [off-list ref] wrote:
IOW, I think that if we do this, we should just get rid of the
"HAVE_DYNAMIC_FTRACE{_XYZ}" config variables entirely, and just make
architectures say
select DYNAMIC_FTRACE if FUNCTION_TRACER
because the "HAVE_xyz" config variables seem to add no actual value,
only confusion.
Or am I missing some reason for still having that extra config
variable indirection?
I always thought the "HAVE_" configs was a way for architectures to state
that it supports something but doesn't necessarily enable it. Whereas the
not "HAVE_" configs are user selectable.
If I go and make all the architectures have:
select DYNAMIC_FTRACE if FUNCTION_TRACER
it seems to be duplicating the work, where all the architectures need to
know the dependencies. To me, that belongs in the generic configs.
The FUNCTION_TRACER config is user selectable, and DYNMIC_FTRACE gets set
when the arch supports dynamic ftrace and the user enables function tracing.
Now, I probably could go and try to clean up some of the HAVE_FTRACE_*
configs. Ftrace has a lot of code that is tightly coupled to architecture
specific code because it relies on trampolines written in assembly.
Throughout the years, I added new features and optimizations that required
architecture fixes. As a lot of the architectures support ftrace but I have
no idea how to update them, I implemented the change in x86 and added a
HAVE_FTRACE_* config so that other architectures could have time to update
to the new feature too and the old way still works.
I should look to see what hasn't been ported to every architecture that
supports ftrace and remove the configs that are now universal.
-- Steve