Re: [PATCH -tip] x86: apic/x2apic_cluster.c x86_cpu_to_logical_apicid should be static

[Ingo Molnar <mingo@elte.hu>]

* Jaswinder Singh Rajput <jaswinder@kernel.org> wrote:

> Impact: reduce kernel size a bit, avoid sparse warning
> 
> Fixes sparse warning:
>   arch/x86/kernel/apic/x2apic_cluster.c:13:1: warning: symbol 'per_cpu__x86_cpu_to_logical_apicid' was not declared. Should it be static?
> 
> Signed-off-by: Jaswinder Singh Rajput <jaswinderrajput@gmail.com>
> ---
>  arch/x86/kernel/apic/x2apic_cluster.c |    2 +-
>  1 files changed, 1 insertions(+), 1 deletions(-)

Applied, thanks.

There is a not so small nit:

> Impact: reduce kernel size a bit, avoid sparse warning
> 
> Fixes sparse warning:

the thing is, we dont 'fix', nor do we 'avoid' Sparse warnings!

We _read_ them, _understand_ them, and then we act upon them, fixing 
the problem they expose.

Or, if there is no problem exposed, we annotate the code to fix the 
Sparse false positive warning.

Your changelog does not tell us anything whether you went through 
that thought process. I had to double-check it and had to create 
this information from scratch.

Please take this as a last warning: you send lots of patches that 
address various things mechanically, often without thinking through 
the effects. They are expensive to maintain, because they cause 
churn and because people often have to do more work accepting them 
than you did creating them!

You sent a hundred patches in two weeks and they are not applied yet 
- and this is why: it is expensive to filter through them and if you 
dont do it we can only do it by simply not taking them all that 
easily. Taking them simply does not scale.

And if you write a hundred patches in two weeks you _really_ have to 
ask yourself whether your quality controls are strong enough before 
emitting them. There are highly productive members of the Linux 
community who only send a dozen patches per _year_.

You really want to avoid the 'also sends clueless patches' 
contributor label, because the only way to deal with such patches as 
a maintainer is to rate-throttle them.

Thanks,

	Ingo