From: Dave Hansen <haveblue@us.ibm.com>
To: linux-ia64@vger.kernel.org
Subject: Re: [lhcs-devel] Re: [RFC] don't create cpu/online sysfs file
Date: Fri, 04 Jun 2004 23:41:05 +0000 [thread overview]
Message-ID: <1086392465.24915.151.camel@nighthawk> (raw)
In-Reply-To: <1086390257.24915.132.camel@nighthawk>
On Fri, 2004-06-04 at 16:17, Ashok Raj wrote:
> I think your solution can be easily solved if all you want to do is
> "your platform does not support cpuhotplug", which case just dont create
> for any cpu, or even better dont do anything in register_cpu() related
> to control file creation. Forcing all implementations to behave one way just to
> do what you want seems not right approach, and limiting all to least common
> denominator.
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().
But, I definitely see the merit in what you want.
> But you should not always assume this is a static decision just because its the
> case in one platform. In my earlier example, if you have 8 cpu system,
> but cpu0-3 are special, and atleast 1 needs to exist for the system to work.
>
> I can remove any of of cpu0-3 until i have atleast one of the cpu0-3 left. The
> last one is not removable.
>
> 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.
The purpose of the patch is originally only to keep ppc64 systems from
making firmware calls that they couldn't support. (Someone tried to
offline a CPU on a system when it wasn't supported and the firmware got
mad)
-- Dave
next prev parent reply other threads:[~2004-06-04 23:41 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 [this message]
2004-06-05 14:38 ` Ashok Raj
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=1086392465.24915.151.camel@nighthawk \
--to=haveblue@us.ibm.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