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
next prev 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