Re: [MAINTAINER SUMMIT] Enforcing API deprecation

Bartosz Golaszewski
2025-08-28T15:11:22Z

On Wed, 27 Aug 2025 at 18:58, Linus Torvalds
<torvalds@linux-foundation.org> wrote:
>
> All I'm saying is that people who do new API's should either just
> accept that, or just convert between the two. None of this "deprecate"
> garbage. None of this "blame other developers because they use the old
> interface".
>

How about "let developers know, people are actively working to replace
this old, bad* API with a better alternative so at least don't
(unknowingly) sabotage their efforts"?

> That's the basic tenet here: if you are too lazy to convert all users,
> you also do not have the moral right to complain about - or expect -
> others not doing the work you didn't do for you.
>

That's just being mean for no reason. I already said it elsewhere in
this thread but let me reiterate: sometimes a new (surely not lazy)
developer shows up and wants to improve an already messy situation
(for instance: remove the cruft resulting from having two APIs that
could be unified with some effort). They may very well not be
responsible for the problem at all. Don't they have the moral right to
at least steer the subsequent development from others in the right
direction if they're willing to do the heavy lifting? No complaining
and no blaming: just advice on how to use a given subsystem. Like, I
don't know, telling user-space to not use sysctl() (the system call)
back in the day because it's bad and was replaced by the /proc/sys
alternative?

And what is it with this "all or nothing" approach? What if it's not
feasible (too many places to fix at once)? I'm not sure telling
someone who wants to improve 1% of the code-base that they "either fix
100% or go away" is a good approach. If the kernel looks better after
this hypothetical conversion, then isn't it worth supporting? Telling
users not to use a specific set of functions and instead go with a
different one isn't really a big issue, is it?

Bartosz

* - The API may have looked good when it was introduced but things
change and new use-cases come up. GPIO would have never needed the big
locking overhaul we did a couple cycles back, had we just kept only
supporting MMIO chips. But things do evolve...