* Andrew Morton <akpm@xxxxxxxxxxxxxxxxxxxx> wrote:
On Fri, 6 Mar 2009 20:12:49 +0100
Ingo Molnar <mingo@xxxxxxx> wrote:
* Yinghai Lu <yinghai@xxxxxxxxxx> wrote:If two architectures are using it then it should be provided by core kernel?
Impact: cleanupBtw., the after_bootmem variable itself should either move to x86 (and arch/sh), or should be defined in mm/bootmem.c.
extend after_bootmem and after_init_bootmem to bootmem_state
and will have BEFORE_BOOTMEM, DURING_BOOTMEM, AFTER_BOOTMEM
v2: style changes according to ingo
Signed-off-by: Yinghai Lu <yinghai@xxxxxxxxxx>
---
arch/x86/kernel/setup.c | 1 +
arch/x86/mm/init.c | 13 +++++++------
arch/x86/mm/init_32.c | 28 ++++++++++++++++++++--------
arch/x86/mm/init_64.c | 33 +++++++++++++++++++--------------
include/linux/mm.h | 9 +++++++++
5 files changed, 56 insertions(+), 28 deletions(-)
Index: linux-2.6/include/linux/mm.h
===================================================================
--- linux-2.6.orig/include/linux/mm.h
+++ linux-2.6/include/linux/mm.h
@@ -1067,6 +1067,15 @@ extern void __init mmap_init(void);
extern void show_mem(void);
extern void si_meminfo(struct sysinfo * val);
extern void si_meminfo_node(struct sysinfo *val, int nid);
+
+enum bootmem_state {
+ BEFORE_BOOTMEM,
+ DURING_BOOTMEM,
+ AFTER_BOOTMEM
+};
+
+extern enum bootmem_state bootmem_state;
+
extern int after_bootmem;
Right now we have this weird mm.h construct that is not actually useful to generic code.
Andrew, what would be your preference?
This is obvious if the state transitions are occurring in core-kernel code, but if the transitions are happening in arch code then making it a core concept assumes consistency between different architectures which might not exist.
IOW: dunno.
Core kernel could provide a wrapper allocator which calls the right method depending on which state we are in. It will call bootmem_alloc() if called early, and kmalloc() if called later. Or something like that. Would there be any utility in that?