All of lore.kernel.org
 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 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.