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?
thanks,
greg k-h
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.
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.
Seth
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
On 08/01/2013 01:57 PM, Greg Kroah-Hartman wrote:
>> > "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.
If there are existing tools or applications that look for memory hotplug
events, how does this interact with those? I know you guys have control
over the ppc software that actually performs the probe/online
operations, but what about other apps?
I also don't seem to see the original post to LKML. Did you send
privately to Greg, then he cc'd LKML on his reply?
On Thu, Aug 01, 2013 at 03:13:03PM -0700, Dave Hansen wrote:
> On 08/01/2013 01:57 PM, Greg Kroah-Hartman wrote:
> >> > "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.
>
> If there are existing tools or applications that look for memory hotplug
> events, how does this interact with those? I know you guys have control
> over the ppc software that actually performs the probe/online
> operations, but what about other apps?
After taking a closer look, I've decided to rework this to preserve more
of the existing layout. Should be posting it next Monday.
>
> I also don't seem to see the original post to LKML. Did you send
> privately to Greg, then he cc'd LKML on his reply?
Yeah :-/ My mail relay settings were messed up and my system tried to
deliver the mail directly to recipients; some of which worked and some
failed (spam/firewall filters, etc). Sigh...
Seth