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

[Linus Torvalds]

" part

On Thu, 3 Jul 2025 at 12:26, Steven Rostedt <rostedt@xxxxxxxxxxx> wrote:
>
> 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.

I don't actually think we have those kinds of rules in practice.

We have very random Kconfig things. A lot of things are "architecture
just selects the feature directly", and the naming is a random
collection of ARCH_HAS_abc, ARCH_USE_abc, ARCH_WANT_abc, HAVE_ARCH_abc
and HAVE_abc.

And those are the patterns that _try_ to be some kind of pattern, and
ignores all the "architecture just selects the feature directly".

Honestly, when we have *five* different syntaxes for "this
architecture supports feature 'abc'", I'd argue that not only isn't
there a standard way, all those different syntax forms are just
confusing.

I get the strong feeling that the reason people have those different
prefixes is literally to just group things together alphabetically -
ie some people use "ARCH_HAS_xyz" just because that way they can put
the "select" statement next to another ARCH_HAS_xyz that they also
maintain.

And then in addition to those various "arch has", we have the
"GENERIC_xyz" Kconfig entries that architectures also select.

I think those GENERIC_xyz Kconfig options may actually have more of a
pattern: that _tends_ to be about "I'm not implementing my own
version, please just pick the generic version". That one is one of our
better patterns, I think.

So the reason I dislike the HAVE_xyz pattern is exactly that there
_isn't_ a pattern. When there are fifteen different patterns, it's not
a pattern at all.

That said, maybe it's better to have one place that has that "if
FUNCTION_TRACER, even if I despise the nonsensical "helper
indirection" just because of the random naming.

              Linus