On 03/21/2010 07:37 PM, Benjamin Herrenschmidt wrote:
quoted text
> On Sun, 2010-03-21 at 00:13 -0700, Yinghai Lu wrote:
>> move it to kernel/fw_memmap.c from arch/x86/kernel/e820.c
>>
>> -v2: add fw_memmap wrapper to some func...
>>      move some functions back to e820.c
> 
> NAK
at this point, kernel/early_res.c and kernel/fw_memmap.c is protected with HAVE_EARLY_RES

obj-$(CONFIG_HAVE_EARLY_RES) += early_res.o fw_memmap.o

so it will not increase size that doesn't support early_res/bootmem yet.
 
quoted text
> 
> This is even worse than before. You are now moving that entire pile of
> x86 gunk into "generic" code, but even keep it names e820 there !

not all of the e820 code. arch/x86/kernel/e820.c are still there.

linux-2.6> wc -l  arch/x86/kernel/e820.c
690 arch/x86/kernel/e820.c
linux-2.6> wc -l kernel/fw_memmap.c
625 kernel/fw_memmap.c

and interface header file

yhlu@linux-siqj:~/xx/xx/kernel/tip/linux-2.6> cat include/linux/fw_memmap.h 
#ifndef _LINUX_FW_MEMMAP_H
#define _LINUX_FW_MEMMAP_H
#define E820MAX	128		/* number of entries in E820MAP */

#define FW_MEMMAP_RAM	1
#define FW_MEMMAP_RESERVED	2

#define E820_RAM	FW_MEMMAP_RAM
#define E820_RESERVED	FW_MEMMAP_RESERVED

#define E820_ACPI	3
#define E820_NVS	4
#define E820_UNUSABLE	5

#ifndef __ASSEMBLY__
#include <linux/types.h>
struct e820entry {
	__u64 addr;	/* start of memory segment */
	__u64 size;	/* size of memory segment */
	__u32 type;	/* type of memory segment */
} __attribute__((packed));

#ifdef __KERNEL__

void fw_memmap_add_region(u64 start, u64 size, int type);
void fw_memmap_print_map(char *who);
int sanitize_fw_memmap(void);
void finish_fw_memmap_parsing(void);

#include <linux/early_res.h>

unsigned long fw_memmap_end_of_ram_pfn(void);
void fw_memmap_register_active_regions(int nid, unsigned long start_pfn,
					 unsigned long end_pfn);
u64 fw_memmap_hole_size(u64 start, u64 end);

#endif /* __KERNEL__ */
#endif /* __ASSEMBLY__ */

#endif /* _LINUX_FW_MEMMAP_H */

and new arch that support early_res/bootmem, will normally only need to call those six functions
like

+void __init setup_memory_map(void)
+{
+       int i;
+       unsigned long phys_base;
+       /* Find available physical memory...
+        *
+        * Read it twice in order to work around a bug in openfirmware.
+        * The call to grab this table itself can cause openfirmware to
+        * allocate memory, which in turn can take away some space from
+        * the list of available memory.  Reading it twice makes sure
+        * we really do get the final value.
+        */
+       read_obp_translations();
+       read_obp_memory("reg", &pall[0], &pall_ents);
+       read_obp_memory("available", &pavail[0], &pavail_ents);
+       read_obp_memory("available", &pavail[0], &pavail_ents);
+
+       phys_base = 0xffffffffffffffffUL;
+       for (i = 0; i < pavail_ents; i++) {
+               phys_base = min(phys_base, pavail[i].phys_addr);
+               fw_memmap_add_region(pavail[i].phys_addr, pavail[i].reg_size,
+                                FW_MEMMAP_RAM);
+       }
+
+       sanitize_fw_memmap();
+
+       fw_memmap_print_map("obp memmap:");


quoted text
> 
> What happened to the discussion we had earlier, which iirc concluded
> that a better approach would be to adapt x86 to use LMB ?

e820/early_res is more complicated than lmb. to make x86, we still need to keep e820 related code.
and early_res already can be used to replace bootmem code.

maybe we should find other user other than previous lmb users at first.

attached is the one for sparc64/lmb converting...- i have no chance to debug it.
qemu seems doesn't support sparc64 well yet.


Yinghai