linuxppc-dev.lists.ozlabs.org archive mirror
 help / color / mirror / Atom feed
From: Dave Hansen <dave@linux.vnet.ibm.com>
To: Nathan Fontenot <nfont@austin.ibm.com>
Cc: linuxppc-dev@ozlabs.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH 3/5 v4] Export memory_sysdev_class
Date: Thu, 22 Oct 2009 08:56:46 -0700	[thread overview]
Message-ID: <1256227006.23737.784.camel@nimitz> (raw)
In-Reply-To: <4AE07AB7.2070901@austin.ibm.com>

On Thu, 2009-10-22 at 10:31 -0500, Nathan Fontenot wrote:
> Dave Hansen wrote:
> > On Wed, 2009-10-21 at 09:44 -0500, Nathan Fontenot wrote:
> >> Export the memory_sysdev_class structure.  This is needed so we can create
> >> a 'release' file in sysfs in addition to the existing 'probe' file in
> >> order to support DLPAR removal of memory on the powerpc/pseries platform.
> >> The new 'release' file will be powerpc/pseries only.
> > 
> > Please do it in generic code.  You may only need it on ppc today, but
> > somebody else is going to want the same thing tomorrow on another arch.
> 
> I thought about this but wasn't sure if having the probe/release sysfs files
> for memory and cpu be in generic code would be accepted.

Although we don't want to pollute the generic code with lots of per-arch
cruft, this still looks pretty generic to me.  It is also really nice to
have all of the sysfs files for one directory be in a single place in
the source.

> Would it be acceptable to put the new release file for memory under the
> ARCH_MEMORY_PROBE config option?

That sounds fine to me.  It may need a slightly tuned name if you can
think of anything better.  I can't off the top of my head.

x86's is really only there for testing reasons.   I would use mem= to
shrink a machine's memory at boot then use the probe file to re-add it
later.  I did that before I had hardware that could do real hotplug.

> This would reduce the number of arch'es
> that would require stubs as it appears only powerpc and x86 define this.

Yeah, that'd be a nice side-effect I guess.

-- Dave

  reply	other threads:[~2009-10-22 15:56 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-10-21 14:35 [PATCH 0/5 v4] Kernel Handling of Dynamic Logical Partitioning Nathan Fontenot
2009-10-21 14:40 ` [PATCH 1/5 " Nathan Fontenot
2009-10-21 14:42 ` [PATCH 2/5 v4] move of_drconf_cell definition to prom.h Nathan Fontenot
2009-10-21 14:44 ` [PATCH 3/5 v4] Export memory_sysdev_class Nathan Fontenot
2009-10-21 16:03   ` Dave Hansen
2009-10-22 15:31     ` Nathan Fontenot
2009-10-22 15:56       ` Dave Hansen [this message]
2009-10-21 14:46 ` [PATCH 4/5 v4] Kernel Handling of memory DLPAR Nathan Fontenot
2009-10-21 14:47 ` [PATCH 5/5 v4] Kernel Handling of cpu DLPAR Nathan Fontenot

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=1256227006.23737.784.camel@nimitz \
    --to=dave@linux.vnet.ibm.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linuxppc-dev@ozlabs.org \
    --cc=nfont@austin.ibm.com \
    /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;
as well as URLs for NNTP newsgroup(s).