On Thu, 2 Aug 2007, Christoph Hellwig wrote: > On Thu, Aug 02, 2007 at 10:25:35AM +0100, Andy Whitcroft wrote: > > + * Special Kconfig settings: > > + * > > + * CONFIG_ARCH_POPULATES_SPARSEMEM_VMEMMAP > > + * > > + * The architecture has its own functions to populate the memory > > + * map and provides a vmemmap_populate function. > > + * > > + * CONFIG_ARCH_POPULATES_SPARSEMEM_VMEMMAP_PMD
?? Why was this added? The arch can populate the PMDs on its own already if CONFIG_ARCH_SPARSEMEM_VMEMMAP is set. > This is the kinda of mess I mean. Which architecturs set either of these > and why? This code would be a lot more acceptable if we hadn't three > different variants of the arch interface. Initially at least my scheme was the following: In general the sparsemem code can take care of a vmemmap that is using a section of the vmalloc space. In that case no arch code is needed to populate the vmemmap. Typical use is by arches with large pages (like IA64). This is the default if no other options are set and can simply be enabled by defining some constants in the arch code to reserve a section of the vmalloc space. Then there is the option of using the PMD to map a higher order page. This can also be done transparently and is used by arches that have this capability and a small page size. Those arches also require no additional code to populate their vmemmap. This is true f.e. for i386 and x86_64. These have to set CONFIG_ARCH_SUPPORTS_PMD_MAPPING Then there are arches that have the vmemmap in non standard ways. Memory may not be taken from the vmalloc space, special flags may have to be set for the page tables (or one may use a different mechanism for mapping). Those arches have to set CONFIG_ARCH_POPULATES_VIRTUAL_MEMMAP. In that case the arch must provide its own function to populate the memory map. - To unsubscribe from this list: send the line "unsubscribe linux-arch" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
