On 04/10/2014 11:14 AM, Li Zhong wrote:
> On Wed, 2014-04-09 at 08:49 -0700, Dave Hansen wrote:
>> On 04/09/2014 02:20 AM, Li Zhong wrote:
>>> Or do you mean we don't need to expose any information related to
>>> SECTION to userspace?
>>
>> Right, we don't need to expose sections themselves to userspace. Do we?
>>
> OK, I agree with that.
>
> Yanfei, I recall you once expressed your preference for section
> numbers?
Hmmm.... Looking at the git log:
commit d33601644cd3b09afb2edd9474517edc441c8fad
Author: Nathan Fontenot <nf...@austin.ibm.com>
Date: Thu Jan 20 10:44:29 2011 -0600
memory hotplug: Update phys_index to [start|end]_section_nr
Update the 'phys_index' property of a the memory_block struct to be
called start_section_nr, and add a end_section_nr property. The
data tracked here is the same but the updated naming is more in line
with what is stored here, namely the first and last section number
that the memory block spans.
The names presented to userspace remain the same, phys_index for
start_section_nr and end_phys_index for end_section_nr, to avoid breaking
anything in userspace.
This also updates the node sysfs code to be aware of the new capability for
a memory block to contain multiple memory sections and be aware of the
memory
block structure name changes (start_section_nr). This requires an
additional
parameter to unregister_mem_sect_under_nodes so that we know which memory
section of the memory block to unregister.
Signed-off-by: Nathan Fontenot <nf...@austin.ibm.com>
Reviewed-by: Robin Holt <h...@sgi.com>
Reviewed-by: KAMEZAWA Hiroyuki <kamezawa.hir...@jp.fujitsu.com>
Signed-off-by: Greg Kroah-Hartman <gre...@suse.de>
So obviously, Nathan added the end_phys_index sysfile to present the last
section
number of a memory block (for end_section_nr), but what he did in the patch
seems not matching the log.
So what is the motivation of adding this 'end_phys_index' file here?
Confused.
--
Thanks.
Zhang Yanfei
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
