Re: [MAINTAINER SUMMIT] Enforcing API deprecation

[Krzysztof Kozlowski <krzk@kernel.org>]

On 27/08/2025 16:47, Bartosz Golaszewski wrote:
> 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 think build-time warnings or emails from LKP about using deprecated
API do solve the problem, in the very long term. Why? We do remove old
platforms, so even if we do not convert in-tree users from deprecated
API, these warnings would reduce amount of new code coming to the
kernel. Eventually at some point we just drop old architectures, old
platforms or drivers and that might be the last user of the deprecated API.


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

Sure, I don't think anyone questions that part. So imagine we maintain
both APIs, but we do not want the old one to grow?

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

How about sparse attributes for the old API as deprecated and in the
same time all existing users as "ignore-that-sparse-warning"? We already
have a few drivers doing:
	#ifdef __CHECKER__
to avoid many false positives (e.g. handling inlines). Also few for
skipping locking (drivers/scsi/qla2xxx/qla_nx.c), but this feels rather
like anti-pattern.

We also have cases of:
	#ifdef CONFIG_CC_IS_GCC
	#pragma GCC diagnostic ignored "-Wsuggest-attribute=format"
	#endif


Best regards,
Krzysztof