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]

Message-ID: <alpine.LFD.2.00.1003222233440.3147@localhost.localdomain>
Date:	Mon, 22 Mar 2010 23:09:26 +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

Yinghai,

On Mon, 22 Mar 2010, Yinghai Lu wrote:
> On 03/22/2010 12:37 PM, Ingo Molnar wrote:
> > * Thomas Gleixner <tglx@...utronix.de> 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-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/