public inbox for linux-ia64@vger.kernel.org
 help / color / mirror / Atom feed
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: Sat, 05 Jun 2004 19:22:21 +0000	[thread overview]
Message-ID: <1086463340.30138.58.camel@nighthawk> (raw)
In-Reply-To: <1086390257.24915.132.camel@nighthawk>

On Sat, 2004-06-05 at 07:38, Ashok Raj wrote:
> 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.

Actually __cpu_is_hotpluggable(cpu) does get called on ia64, it's just a
trivially-defined 'return 1' for now.  Are there ever any plans to run
an kernel with CONFIG_HOTPLUG_CPU on an ia64 machine that doesn't really
support cpu hotplug?  If so, I'd be happy to include the same
functionality on ia64 that I put for ppc64.

BTW, the reason that this is done on ppc64 is that we can run the same
kernel on a wide variety of hardware, so it makes the distributions'
jobs a bit easier.  

> you are adding an extra arch function just for a trivial thing, not to create a 
> control 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.

The non-trivial thing that this patch tries to do is give the user some
knowledge about the system from the pure layout of sysfs.  Waiting until
__cpu_disable() to tell the user that there was no possibility of the
cpu being offlined seems a bit late in the process.  Your idea about the
cpuinfo file in sysfs is definitely right; it has *exactly* the
information that I'm trying to present.  But, the current sysfs
guidelines tend to discourage single files with lots of information like
those in /proc.  

-- Dave


  parent reply	other threads:[~2004-06-05 19:22 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
2004-06-05 19:22 ` Dave Hansen [this message]
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=1086463340.30138.58.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