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 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.