From: Benjamin Herrenschmidt on
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(a)kernel.org>
> ---
> 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-kernel" in
the body of a message to majordomo(a)vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/