linuxppc-dev.lists.ozlabs.org archive mirror
 help / color / mirror / Atom feed
From: Michael Ellerman <michael@ellerman.id.au>
To: Chen Gang <gang.chen@asianux.com>
Cc: "linuxppc-dev@lists.ozlabs.org" <linuxppc-dev@lists.ozlabs.org>,
	Thomas Gleixner <tglx@linutronix.de>,
	"paulus@samba.org" <paulus@samba.org>,
	chenhui.zhao@freescale.com,
	"Srivatsa S. Bhat" <srivatsa.bhat@linux.vnet.ibm.com>
Subject: Re: [PATCH v2] powerpc: kernel: remove useless code which related with 'max_cpus'
Date: Thu, 25 Jul 2013 13:15:01 +1000	[thread overview]
Message-ID: <20130725031501.GA15673@concordia> (raw)
In-Reply-To: <51EF375D.9060006@asianux.com>

On Wed, Jul 24, 2013 at 10:09:33AM +0800, Chen Gang wrote:
> On 07/24/2013 09:16 AM, Michael Ellerman wrote:
> > On Wed, Jul 24, 2013 at 08:28:07AM +0800, Chen Gang wrote:
> >> > On 07/23/2013 09:44 PM, Michael Ellerman wrote:
> >>> > > On Mon, Jul 22, 2013 at 12:21:16PM +0530, Srivatsa S. Bhat wrote:
> >>>> > >> On 07/22/2013 12:10 PM, Chen Gang wrote:
> >>>>> > >>> Since not need 'max_cpus' after the related commit, the related code
> >>>>> > >>> are useless too, need be removed.
> >>> > > 
> >>> > > A good follow up patch, or actually series of patches, would be to
> >>> > > change the prototype of smp_ops->probe() to return void, and fix all the
> >>> > > implementations to no longer return anything.
> >>> > > 
> >> > 
> >> > Hmm... normally, a function need have a return value, it will make it
> >> > more extensible (especially, it is an API which need be implemented in
> >> > various sub modules).
> > A function doesn't need a return value, and if it needs one in future then
> > we'll add it then. We don't carry code around "just in case".
> 
> But for API (also include the internal API), at least, better to always
> provide the return value which can indicate failure by negative number
> (if succeed can return the meanness value, e.g. the number of cpus).

Are we still talking about this?

There is no point returning a value when no one checks it. Which is the
case here.

For a published API maybe it's a good idea to have a return value "just
in case", but this is kernel internal and we own both the implementation
and the callers of the API.

> >> > Even though the return value may be useless, now, if the performance is
> >> > not quite important in our case, I still suggest to have it (especially
> >> > each various original implementation already has it).

> > It's dead code, it should be removed.
> 
> For API, if not cause the real world issue, better to keep compatible
> (especially, the return value still can indicate failure by negative
> number).

No. Dead code is a real world issue. If we ever need a return value
we'll add one then.

cheers

  reply	other threads:[~2013-07-25  3:15 UTC|newest]

Thread overview: 24+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-07-22  5:58 [PATCH] powerpc: kernel: remove useless code which related with 'max_cpus' Chen Gang
2013-07-22  6:18 ` Srivatsa S. Bhat
2013-07-22  6:27   ` Chen Gang
2013-07-22  6:40     ` [PATCH v2] " Chen Gang
2013-07-22  6:51       ` Srivatsa S. Bhat
2013-07-22  7:03         ` Chen Gang
2013-07-23 13:44         ` Michael Ellerman
2013-07-24  0:28           ` Chen Gang
2013-07-24  1:16             ` Michael Ellerman
2013-07-24  2:09               ` Chen Gang
2013-07-25  3:15                 ` Michael Ellerman [this message]
2013-07-25  4:02                   ` Chen Gang
2013-07-25  5:16                   ` Benjamin Herrenschmidt
2013-07-25  5:24                     ` Chen Gang
2013-07-25  5:51                       ` Benjamin Herrenschmidt
2013-07-25  6:03                         ` Benjamin Herrenschmidt
2013-07-25  6:30                           ` Chen Gang
2013-07-25  6:17                         ` Chen Gang
2013-07-25  7:33                           ` Benjamin Herrenschmidt
2013-07-25  7:59                             ` Chen Gang
2013-07-25  8:06                               ` Benjamin Herrenschmidt
2013-07-25  8:22                                 ` Chen Gang
2013-07-25  8:28                                   ` Benjamin Herrenschmidt
2013-07-25  8:36                                     ` Chen Gang

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=20130725031501.GA15673@concordia \
    --to=michael@ellerman.id.au \
    --cc=chenhui.zhao@freescale.com \
    --cc=gang.chen@asianux.com \
    --cc=linuxppc-dev@lists.ozlabs.org \
    --cc=paulus@samba.org \
    --cc=srivatsa.bhat@linux.vnet.ibm.com \
    --cc=tglx@linutronix.de \
    /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;
as well as URLs for NNTP newsgroup(s).