" part
On Thu, 3 Jul 2025 at 12:26, Steven Rostedt [off-list ref] 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