Re: [PATCH 06/20] early_res: seperate common memmap func from e820.c to fw_memmap.cy

[Yinghai Lu <yinghai@kernel.org>]

On 03/23/2010 09:24 PM, Benjamin Herrenschmidt wrote:
> On Tue, 2010-03-23 at 09:02 +0100, Ingo Molnar wrote:
>>> -u64 find_fw_memmap_area(u64 start, u64 end, u64 size, u64 align);
>>> +u64 find_lmb_area(u64 start, u64 end, u64 size, u64 align);
>>> +u64 find_lmb_area_size(u64 start, u64 *sizep, u64 align);
>>> +u64 find_lmb_area_node(int nid, u64 start, u64 end, u64 size, u64
>> align);
>>> +void lmb_register_active_regions(int nid, unsigned long start_pfn,
>>> +                                      unsigned long last_pfn);
>>> +u64 lmb_hole_size(u64 start, u64 end);
>>>  u64 get_max_mapped(void);
>>>  #include <linux/range.h>
>>>  int get_free_all_memory_range(struct range **rangep, int nodeid);
>>
>> those new lmb_*() APIs should go into lmb.h.
> 
> And while at it properly documented :-) I wouldn't mind also a
> reasonably clear explanation in the changeset comment as to why
> they are necessary for x86.

new early_res.c will have
find_lmb_area
reserve_early
free_early
also have get_free_all_memory_range to support bootmem replacement.

find_lmb_area: will take goal/limit, so we can find free region with more control.

when we try to check if there is enough slots for new reserve entry.
we need to make sure the new array will not overlap with range below to
entry that going to be reserved.
so we need to goal for find.
otherwise you have to keep trying with lmb_alloc until get one for new array
that will not overlap with new entry.


> 
> To be honest, that's my #1 grief so far with this entire patch set,
> it Yinghai apparent inability to write anything ressembling remotely
> like an explanation. All we get is key words, bullet points and half
> sentences, and I admit have a very very hard time extracting a meaning
> out of anything he's been writing so far.

will spend more time to write more sentences...

thought you guys like to read code instead.

Thanks for you patience.

Yinghai Lu