public inbox for linux-ia64@vger.kernel.org
 help / color / mirror / Atom feed
From: Ashok Raj <ashok.raj@intel.com>
To: linux-ia64@vger.kernel.org
Subject: Re: [lhcs-devel] Re: [RFC] don't create cpu/online sysfs file
Date: Sat, 05 Jun 2004 14:38:02 +0000	[thread overview]
Message-ID: <20040605073802.A22026@unix-os.sc.intel.com> (raw)
In-Reply-To: <1086390257.24915.132.camel@nighthawk>

On Fri, Jun 04, 2004 at 04:41:05PM -0700, Dave Hansen wrote:
> 
> That's originally what I did.  A single global function to see if the
> platform supported cpu hotplug at runtime.  The addition of passing the
> 'struct cpu' to it was so trivial that I figured it might be useful to
> someone down the line.  I'm regretting my "foresight" now :)
> 
> > The preferable way to this would be.
> > 
> > - platfform_supports_cpuhotplug(), like in your case, dont create the 
> >   online file for any.
> > - __cpu_is_hotpluggable(cpu#) can also exist if this is a static decision to 
> >    be made, say if the platform says that a certain cpu cannot be removed. 
> 
> That seems to be a pretty sensible way to do it.  However, we keep the
> number of interfaces from generic to arch code down if we keep the
> interface confined to 1 function.  It would be trivial to make any
> architecture that needs it do this:
> 
> int __cpu_is_hotpluggable(struct cpu *cpu)
> {
> 	if (!platfform_supports_cpuhotplug())
> 		return 0;
> 
> 	lots();
> 	of_complex_arch_code();
> 	here();
> 	...
> }
> 
> That ensures that there's only 1 function that needs to be defined
> globally: __cpu_is_hotpluggable().
> 

I feel the __cpu_disable() should be just sufficient to be the only
function interface from generic to arch code. You run this
__cpu_is_hotpluggable(cpu) only in ppc64, where you check and return error.
maybe also printing to console saying the platform doesnt support it.

you are adding an extra arch function just for a trivial thing, not to create a 
control file. 

> > 
> > Keep it simple please:-)
> 
> That's what I'm trying to to :)
> 
> I was thinking that cpuX/online is only there to say whether hotplug
> _operations_ are supported on the cpu, not if it can be hotplugged right
> now.  The "can currently be hotplugged" question is another can of worms
> that can't really be answered until the hotplug request is made anyway,
> so I'd prefer to keep from trying to decide that by the presence of the
> file.
My recommendation is to not do anything, and just let __cpu_disable() handle it.
print some verbose message for the operator that this aint going to work should
be more than sufficient. There is not a whole lot of realusefullness for this 
to work.

we if overdo something here, then memory hotplug, node hotplug would all need
to do the same hack, __is_node_hotpluggable(node), is_memsection_hotpluggabe(mem)
and so on....

Cheers,
ashok

  parent reply	other threads:[~2004-06-05 14:38 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2004-06-04 23:04 [lhcs-devel] Re: [RFC] don't create cpu/online sysfs file Dave Hansen
2004-06-04 23:17 ` Ashok Raj
2004-06-04 23:41 ` Dave Hansen
2004-06-05 14:38 ` Ashok Raj [this message]
2004-06-05 19:22 ` Dave Hansen
2004-06-06 20:27 ` Ashok Raj
2004-06-07  5:05 ` Dave Hansen
2004-06-07 14:07 ` Nathan Lynch
2004-06-07 14:08 ` Ashok Raj
2004-06-07 14:14 ` Ashok Raj
2004-06-07 16:41 ` Dave Hansen
2004-06-07 17:22 ` Ashok Raj
2004-06-07 19:25 ` Dave Hansen
2004-06-07 20:48 ` Ashok Raj
2004-06-09  7:10 ` Andrew Morton
2004-06-09 14:27 ` Ashok Raj

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=20040605073802.A22026@unix-os.sc.intel.com \
    --to=ashok.raj@intel.com \
    --cc=linux-ia64@vger.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