Re: [MAINTAINER SUMMIT] Enforcing API deprecation

[Linus Torvalds <torvalds@linux-foundation.org>]

On Tue, 26 Aug 2025 at 12:58, Bartosz Golaszewski
<bartosz.golaszewski@linaro.org> wrote:
>
> 1. Use gcc's __attribute__((deprecated)) (Linus doesn't like it

No. Unacceptable. We do not introduce warnings that aren't immediately fixed.

And no - this isn't even getting discussed. The kernel stays
warning-free, which means that "__attribute__((deprecated))" isn't
something that "Linus doesn't like". It's simply NOT AN OPTION.

> 2. Use keywords in MAINTAINERS entries (this sounds like an abuse of
> what this file is really for and can sometimes be hard to get right.
> Also: see above about it not being very efficient).
> 3. Make checkpatch.pl check the patches for new uses of deprecated
> APIs (similarly to what it does for invalid usage of memory and log
> helpers)
> 4. Make build bots detect it.

Fine, but doesn't solve anything.

> I would like to propose a discussion on how to enforce API deprecation
> in a way that supports efforts to reduce technical debt, without being
> hampered by developers and maintainers who mean no harm but simply
> don’t know any better.

Here's the only thing that works: if you change the API, you have to
fix up all existing users.

If you are not willing to fix up all existing users, and you introduce
a parallel API, then you are the one that maintains both the old and
the new API forever.

Or at least until somebody else did the work that you weren't willing to do.

End result: the burden of new / different API's is on the person
introducing them. IOW: don't introduce new API's unless you are
willing to support them.

             Linus