Yinghai,
On Mon, 22 Mar 2010, Yinghai Lu wrote:
> On 03/22/2010 12:37 PM, Ingo Molnar wrote:
> > * Thomas Gleixner <tglx@xxxxxxxxxxxxx> wrote:
>
> >> The main point is that there is still no answer why lmb cannot be used and
> >> the reposted patch still is a full move of the x86 e820 functions into
> >> kernel/fw_memmap.c.
> >>
> >> That's not a generalization, that's simply a relocation of x86 code to
> >> kernel/. And I agree with Dave and Ben that this is an useless exercise.
> >
> > ok - i think you are right. Yinghai, mind having a look at using
> > lib/lmb.c for all this?
>
> 1. need to keep e820
That's neither an argument for using lmb nor an argument not to use
lmb. e820 is x86 specific BIOS wreckage and it's whole purpose is
just to feed information into a (hopefully) generic early resource
management facility.
e820 _CANNOT_ be generalized. Period.
> 2. use e820 range with RAM to fill lmb.memory when finizing_e820
What's finizing_e820 ???
> 3. use lmb.reserved to replace early_res.
What's the implication of doing that ?
> current lmb is merging the region, we can not use name tag any more.
What's wrong with merging of regions ? Are you arguing about a
specific region ("the region") ?
Which name tag ? And why is that name tag important ?
> may need to dump early_memtest, and use early_res for bootmem at
> first.
Why exactly might early_memtest not longer be possible ?
What means "early_res for bootmem" ?
Please take some time to explain in detail. Throwing one liners and
buzzwords w/o context into such a discussion is more than counter
productive.
Thanks,
tglx
--
To unsubscribe from this list: send the line "unsubscribe linux-arch" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
