On Thu, 3 Jul 2025 at 08:52, Steven Rostedt <[email protected]> wrote:
>
> Remove the prompt to pick DYNAMIC_FTRACE and simply enable it if the
> architecture supports it.
I don't disagree with removing pointless Kconfig options, but if we do
this, we should do it properly.
Because now we have that entirely pointless "HAVE_DYNAMIC_FTRACE*" set
of config options. Which with this patch would be just stupid and
extra indirection that makes things harder to see.
IOW, with this patch we'd have
(a) architectures that support dynamic ftrace will do
select HAVE_DYNAMIC_FTRACE
select HAVE_DYNAMIC_FTRACE_WITH_REGS
(or whatever combination)
and then
(b) kernel/trace/Kconfig will just turn that into the proper
DYNAMIC_FTRACE_xyz macros
and when this no longer involves any questions, there is absolutely
*zero* reason I can see for that pointless indirection through another
config variables.
Yes, yes, there's still the "depends on FUNCTION_TRACER" that
technically is a "reason" for that indirection, but it seems to be a
reall ybad one.
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?
Linus
