lkml.org 
[lkml]   [2010]   [Mar]   [22]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH 06/20] early_res: seperate common memmap func from e820.c to fw_memmap.cy
On Mon, 22 Mar 2010, Yinghai Lu wrote:
> On 03/22/2010 03:09 PM, Thomas Gleixner wrote:
> > On Mon, 22 Mar 2010, Yinghai Lu wrote:
> >> On 03/22/2010 12:37 PM, Ingo Molnar wrote:
>
> >> 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.

I still want to know, what "need to keep e820" means for you.

> >> 2. use e820 range with RAM to fill lmb.memory when finizing_e820
> >
> > What's finizing_e820 ???
> finish_e820_parsing();

Yinghai, come on. Are you really expecting that everyone involved in
this discussion goes to look up what the heck finish_e820_parsing()
is doing ?

You want to explain why your solution is better or why lmb is not
sufficient, so you better go and explain what finish_e820_parsing()
is, why finish_e820_parsing() is important and why lmb cannot cope
with it.

> >> 3. use lmb.reserved to replace early_res.
> >
> > What's the implication of doing that ?
>
> early_res array is only corresponding to lmb.reserved, aka reserved
> region from kernel.

Is it only corresponding (somehow) or is it a full equivivalent ?

> >> 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") ?

Care to answer my question ?

> >
> > Which name tag ? And why is that name tag important ?
>
> struct early_res {
> u64 start, end;
> char name[15];
> char overlap_ok;
> };

I'm starting to get annoyed, really. What is that name field for and
why is that "name" field important ?

> >
> >> may need to dump early_memtest, and use early_res for bootmem at
> >> first.
> >
> > Why exactly might early_memtest not longer be possible ?
>
> early_memtest need to call find_e820_area_size
> current lmb doesn't have that kind of find util.
> the one memory subtract reserved memory by kernel.

What subtracts what ? And why is it that hard to fix that ?

> >
> > What means "early_res for bootmem" ?
>
> use early_res to replace bootmem, the CONFIG_NO_BOOTMEM.
> that need early_res can be double or increase the slots automatically.

-ENOPARSE

Yinghai, I asked you to take your time and explain things in detail
instead of shooting unparseable answers within a minute.

Everyone else in this discussion tries to be as explanatory as
possible, just you expect that everyone else is going to dig out the
crystal ball to understand the deeper meanings of your patches.

Again, please take your time to explain what needs to be done or what
is impossible to solve in your opinion, so we can get that resolved in
a way which is satisfactory and useful for all parties involved.

Thanks,

tglx


\
 
 \ /
  Last update: 2010-03-22 23:57    [W:0.085 / U:0.204 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site