# Cced some people maybe interested in this topic. On Mon, Mar 02, 2015 at 04:04:59AM +0000, Sheng Yong wrote: > There may be memory holes in a memory section, and because of that we can > not know the real size of the section. In order to know the physical memory > area used int one memory section, we walks through iomem resources and > report the memory range in /sys/devices/system/memory/memoryX/range, like, > > root@ivybridge:~# cat /sys/devices/system/memory/memory0/range > 00001000-0008efff > 00090000-0009ffff > 00100000-07ffffff > > Signed-off-by: Sheng Yong <shengyong1@xxxxxxxxxx> About a year ago, there was a similar request/suggestion from a library developer about exporting valid physical address range (http://thread.gmane.org/gmane.linux.kernel.mm/115600). Then, we tried some but didn't make it. So if you try to solve this, please consider some points from that discussion: - interface name: just 'range' might not be friendly, if the interface returns physicall address range, something like 'phys_addr_range' looks better. - prefix '0x': if you display the value range in hex, prefixing '0x' might be better to avoid letting every parser to add it in itself. - supporting node range: your patch is now just for memory block interface, but someone (like me) are interested in exporting easy "phys_addr <=> node number" mapping, so if your approach is easily extensible to node interface, it would be very nice to include node interface support too. Thanks, Naoya Horiguchi -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@xxxxxxxxx. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: <a href