On Thu, 2008-02-14 at 09:12 -0800, Dave Hansen wrote: .. > > > > - Use currently other not exported functions in kernel/resource.c, like > > > > walk_memory_resource (where we would still need the maximum > > > possible number > > > > of pages NR_MEM_SECTIONS) > > > > > > It isn't the act of exporting that's the problem. It's making sure that > > > the exports won't be prone to abuse and that people are using them > > > properly. You should assume that you can export and use > > > walk_memory_resource(). > > > > So this seems to come down to a basic question: > > New hardware seems to have a tendency to get "private MMUs", > > which need private mappings from the kernel address space into a > > "HW defined address space with potentially unique characteristics" > > RDMA in Openfabrics with global MR is the most prominent example heading > > there > > That's not a question. ;) > > Please explain to me why walk_memory_resource() is insufficient for your > needs. I've now pointed it out to you at least 3 times.
I am not sure what you are trying to do with walk_memory_resource(). The behavior is different on ppc64. Hotplug memory usage assumes that all the memory resources (all system memory, not just IOMEM) are represented in /proc/iomem. Its the case with i386 and ia64. But on ppc64 is contains ONLY iomem related. Paulus didn't want to export all the system memory into /proc/iomem on ppc64. So I had to workaround by providing arch-specific walk_memory_resource() function for ppc64. Thanks, Badari -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
