linux-kernel - Re: [PATCH 06/20] early_res: seperate common memmap func from e820.c to fw

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Mon, 22 Mar 2010 23:53:49 +0100 (CET)
From:	Thomas Gleixner <tglx@...utronix.de>
To:	Yinghai Lu <yinghai@...nel.org>
cc:	Ingo Molnar <mingo@...e.hu>, David Miller <davem@...emloft.net>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Linus Torvalds <torvalds@...ux-foundation.org>,
	benh@...nel.crashing.org, hpa@...or.com, jbarnes@...tuousgeek.org,
	ebiederm@...ssion.com, linux-kernel@...r.kernel.org,
	linux-arch@...r.kernel.org
Subject: Re: [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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/