On Thu, 2010-07-22 at 11:43 -0700, Yinghai Lu wrote: > size is returned according free range. > Will be used to find free ranges for early_memtest and memory corruption check > > Do not mess it up with lib/memblock.c yet. So I'm readying my branch which incudes your 6 patches, however I'm still not happy with a few things. For example, I really really don't like exporting memblock_reserved_init_regions. So you do those things for the sake of x86, so let's walk through your x86 patches and see if I can figure out what you do wrong :-) > Signed-off-by: Yinghai Lu <yinghai@xxxxxxxxxx> > --- > arch/x86/include/asm/memblock.h | 8 ++++ > arch/x86/mm/Makefile | 2 + > arch/x86/mm/memblock.c | 88 +++++++++++++++++++++++++++++++++++++++ > 3 files changed, 98 insertions(+), 0 deletions(-) > create mode 100644 arch/x86/include/asm/memblock.h > create mode 100644 arch/x86/mm/memblock.c > > diff --git a/arch/x86/include/asm/memblock.h b/arch/x86/include/asm/memblock.h > new file mode 100644 > index 0000000..c14219a > --- /dev/null > +++ b/arch/x86/include/asm/memblock.h > @@ -0,0 +1,8 @@ > +#ifndef _X86_MEMBLOCK_H > +#define _X86_MEMBLOCK_H > + > +#define ARCH_DISCARD_MEMBLOCK So I'm no fan of this ARCH_DISCARD_MEMBLOCK, especially since it makes a lot of sense to keep the debugfs files around or maybe even move to sysfs for diagnostic purposes. Maybe we should consider something better by having memblock always be init/initdata but we copy the arrays to a "final" location from an initcall ? We can keep your patches for now, but I think we should improve on that. > +u64 memblock_x86_find_in_range_size(u64 start, u64 *sizep, u64 align); I really really don't like your function naming. The above doesn't give me any bloody idea about what the purpose of the function is... Cheers, Ben. -- To unsubscribe from this list: send the line "unsubscribe linux-arch" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
