On Mon, Mar 12, 2012 at 11:40 PM, Avery Pennarun [off-list ref] wrote:

quoted

that seems not right.

for x86, setup_log_buf(1) is quite early called in setup_arch() before
bootmem is there.

bootmem should be killed after memblock is supported for arch that
current support bootmem.

Hmm.  x86 uses nobootmem.c, which implements bootmem in terms of
memblock anyway.  It is definitely working at setup_log_buf() time (or
else it wouldn't be able to select a sensible buffer location).

ok, you may could do that now.
only after recent changes from Tejun, that kill early_node_map().

before that, we only can use nobootmem after
arch/x86/kernel/setup.c::setup_arch/initmem_init()
but memblock alloc could be used just after
arch/x86/kernel/setup.c::setup_arch/memblock_x86_fill()

Now you put back bootmem calling early, will cause confusion.

I suppose you're saying that it wouldn't work for a hypothetical
architecture that *does* support bootmem and *also* supports
setup_log_buf(1).  Will there ever be such an architecture, or will
bootmem be retired first?

we should use adding memblock_alloc calling instead... go backward...

Thanks

Yinghai

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Fight unfair telecom internet charges in Canada: sign http://stopthemeter.ca/
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>