From: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
To: Seth Jennings <sjenning@linux.vnet.ibm.com>
Cc: Nathan Fontenot <nfont@linux.vnet.ibm.com>,
Andrew Morton <akpm@linux-foundation.org>,
"Rafael J. Wysocki" <rafael.j.wysocki@intel.com>,
Nivedita Singhvi <niv@us.ibm.com>,
Michael J Wolf <mjwolf@us.ibm.com>,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH] drivers: base: new memory config sysfs driver for large memory systems
Date: Fri, 2 Aug 2013 04:57:24 +0800 [thread overview]
Message-ID: <20130801205724.GA13585@kroah.com> (raw)
In-Reply-To: <20130726144251.GB4379@variantweb.net>
On Fri, Jul 26, 2013 at 09:42:51AM -0500, Seth Jennings wrote:
Sorry for the delay, google decided to mark your responses as "spam" :(
> On Thu, Jul 25, 2013 at 04:40:07PM -0700, Greg Kroah-Hartman wrote:
> > On Thu, Jul 25, 2013 at 04:11:20PM -0500, Seth Jennings wrote:
> > > +#define MEMFS_CLASS_NAME "memoryfs"
> >
> > One question, a "*fs" name in the kernel usually implies it is a
> > separate filesystem, which this isn't at all, it's just a "normal"
> > class/subsystem in the kernel. So how about "memory" instead?
>
> "memory" is the name used by the current sysfs memory layout code in
> drivers/base/memory.c. So it can't be the same unless we are going to
> create a toggle a boot time to select between the models, which is
> something I am looking to add if this code/design is acceptable to
> people.
I know it can't be the same, but this is like "memory_v2" or something,
right? I suggest you make it an either/or option, given that you feel
the existing layout just will not work properly for you.
> The design is that people with large memory systems would pass a boot
> parameter that selects this alternate layout, so that the majority
> of non-large-memory users and any userspace programs that depend on the
> old layout would be unaffected.
>
> In the meantime, the name "memfs" was chosen for the RFC so that people
> could compile and run the new model concurrently with the current model.
It's a really bad name for a driver subsystem, please don't use it.
thanks,
greg k-h
next prev parent reply other threads:[~2013-08-01 20:56 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <1374786680-26197-1-git-send-email-sjenning@linux.vnet.ibm.com>
2013-07-25 23:38 ` [PATCH] drivers: base: new memory config sysfs driver for large memory systems Greg Kroah-Hartman
2013-07-26 14:33 ` Seth Jennings
2013-08-01 20:57 ` Greg Kroah-Hartman
2013-07-25 23:40 ` Greg Kroah-Hartman
2013-07-26 14:42 ` Seth Jennings
2013-08-01 20:57 ` Greg Kroah-Hartman [this message]
2013-08-01 22:13 ` Dave Hansen
2013-08-01 22:13 ` Dave Hansen
2013-08-02 15:50 ` Seth Jennings
2013-08-02 15:50 ` Seth Jennings
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=20130801205724.GA13585@kroah.com \
--to=gregkh@linuxfoundation.org \
--cc=akpm@linux-foundation.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mjwolf@us.ibm.com \
--cc=nfont@linux.vnet.ibm.com \
--cc=niv@us.ibm.com \
--cc=rafael.j.wysocki@intel.com \
--cc=sjenning@linux.vnet.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.