On Mon, Mar 12, 2012 at 11:40 PM, Avery Pennarun <apenwarr@xxxxxxxxx> wrote: >> 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@xxxxxxxxx. 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