Re: [RFC][PATCH] ftrace: Make DYNAMIC_FTRACE always enabled for architectures that support it

[Steven Rostedt <rostedt@goodmis.org>]

On Thu, 3 Jul 2025 09:57:37 -0700
Linus Torvalds <torvalds@linux-foundation.org> 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