From: Jaswinder Singh Rajput <jaswinder@kernel.org>
To: Ingo Molnar <mingo@elte.hu>
Cc: x86 maintainers <x86@kernel.org>,
Suresh Siddha <suresh.b.siddha@intel.com>,
LKML <linux-kernel@vger.kernel.org>,
Sam Ravnborg <sam@ravnborg.org>
Subject: Re: [PATCH -tip] x86: apic/x2apic_cluster.c x86_cpu_to_logical_apicid should be static
Date: Sun, 12 Apr 2009 17:17:38 +0530 [thread overview]
Message-ID: <1239536858.2976.6.camel@ht.satnam> (raw)
In-Reply-To: <20090412105132.GA25392@elte.hu>
Hello Ingo,
On Sun, 2009-04-12 at 12:51 +0200, Ingo Molnar wrote:
> * 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_.
>
OK, I will be more careful and spend more time on each patch by this way
count will be reduce and quality will also improve.
Please check [git-pull -tip] x86: declaration patches
Sam and Thomas reviewed them and I also fixed the pointed issues.
My problem is I am work-addict I can not sit ideal ;-)
Thanks for your advice,
--
JSR
next prev parent reply other threads:[~2009-04-12 11:49 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-04-11 7:25 [PATCH -tip] x86: apic/x2apic_cluster.c x86_cpu_to_logical_apicid should be static Jaswinder Singh Rajput
2009-04-12 10:39 ` [tip:x86/cleanups] " Jaswinder Singh Rajput
2009-04-12 10:51 ` [PATCH -tip] " Ingo Molnar
2009-04-12 11:47 ` Jaswinder Singh Rajput [this message]
2009-04-12 11:21 ` [tip:x86/cleanups] " Jaswinder Singh Rajput
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1239536858.2976.6.camel@ht.satnam \
--to=jaswinder@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@elte.hu \
--cc=sam@ravnborg.org \
--cc=suresh.b.siddha@intel.com \
--cc=x86@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox