All of lore.kernel.org
 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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.