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: <20100322212013.GB25254@elte.hu>
Date:	Mon, 22 Mar 2010 22:20:13 +0100
From:	Ingo Molnar <mingo@...e.hu>
To:	Benjamin Herrenschmidt <benh@...nel.crashing.org>
Cc:	Paul Mackerras <paulus@...ba.org>,
	David Miller <davem@...emloft.net>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Linus Torvalds <torvalds@...ux-foundation.org>,
	yinghai@...nel.org, tglx@...utronix.de, 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.c

* Benjamin Herrenschmidt <benh@...nel.crashing.org> wrote:

> On Mon, 2010-03-22 at 14:05 +0100, Ingo Molnar wrote:
> > * Paul Mackerras <paulus@...ba.org> wrote:
> > 
> > > And I don't see the point of moving the x86 e820 stuff into the kernel 
> > > directory. [...]
> > 
> > I dont see the point of that either - that is a mistake. e820 is an x86 bios 
> > call and we shouldnt name a generic mechanism after that. e820 is absolutely 
> > messy and has no place anywhere beyond x86.
> > 
> > The main technical argument i see is 'early_res versus LMB'. Even there i'd 
> > prefer LMB from a technical quality POV.
> 
> Then we have no argument. The point is, we object to that fw_memmap/e820 
> stuff taking over for non-x86 architectures. We aren't saying that x86 
> -must- move to LMB, but if the wish is to have a common implementation in 
> generic code accross all archs, -then- we object to it being e820.

Ok, just in case i wasnt clear enough in my first reply (and i guess your mail 
means i wasnt): that whole-sale move of e820 into kernel/fw_memmap.c is a 
total non-starter as far as i'm concerned.

And i kind of like the 'logical memory block' name - it is more intuitive than 
'early_res' (which was always a misnomer IMO, just couldnt find a better name 
for it and it stuck with us).

So no arguments from me at all about the code quality aspects - i just wanted 
to highlight the huge amount of non-trivial work Yinghai has invested into 
this already, with little external help, and that if possible it would be nice 
to minimize the upsetting of related x86 code if possible. Please help him out 
with more specific suggestions about how the two memory allocation spaces 
could be unified best, to serve the needs of all these architectures - if you 
have some spare time.

Thanks,

	Ingo
--
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/