Re: [MAINTAINER SUMMIT] Enforcing API deprecation

[Bartosz Golaszewski <bartosz.golaszewski@linaro.org>]

On Tue, 26 Aug 2025 at 22:12, Linus Torvalds
<torvalds@linux-foundation.org> wrote:
>
> On Tue, 26 Aug 2025 at 12:58, Bartosz Golaszewski
> <bartosz.golaszewski@linaro.org> wrote:
> >

[snip]

> > 4. Make build bots detect it.
>
> Fine, but doesn't solve anything.
>

How so? The developer gets an email telling them they used a legacy
API, the maintainer sees a build bot report and knows to ignore the
patch. That's already better than what we (don't) have currently.

> > 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.
>

That sounds great in theory but in practice, one may be willing to do
the work and it will still take years (as is the case with GPIO) where
there were thousands of calls to the legacy API and - due to the
nature of the differences between the old and new one - the
conversions are far from trivial.

I'm not advocating a policy change, I'm trying to bring up the subject
of making the effort easier for those who participate in the tree-wide
refactoring.

> 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.
>

I would assume, kernel developers in general and maintainers in
particular want to make linux better. An old API may have been
introduced long ago in times where we didn't know what we didn't know
(or even implemented by completely different people altogether) and
the new one, implemented later, is objectively better.

Sometimes a new API is close enough to the old one, that it can simply
be wrapped in backward compatible inline functions and the
implementation is the same for both. That's awesome and supporting the
legacy interface is not a big problem in this case. However, in other
cases, the underlying change in philosophy can be so fundamental that
we effectively end up with two intertwined implementations where a lot
of code could simply be removed once we unify all the users. In our
case, the work IS happening and several people are contributing. My
point is: this effort is commendable and should be supported rather
than brushed off with a "that's the API's author problem". I'm sure I
don't have to even name the advantages of having less code to
maintain.

And to address your last sentence on a personal note: thing's arent
always so black and white - for me: I inherited the GPIO subsystem
with both the old and the new API already present tree-wide and am
just trying to improve the pre-existing situation.

Thanks,
Bartosz