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 22:30:26 +1100
From:	Paul Mackerras <paulus@...ba.org>
To:	Ingo Molnar <mingo@...e.hu>
Cc:	David Miller <davem@...emloft.net>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Linus Torvalds <torvalds@...ux-foundation.org>,
	yinghai@...nel.org, benh@...nel.crashing.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

On Mon, Mar 22, 2010 at 10:28:09AM +0100, Ingo Molnar wrote:

> ( Cc:-ed Andrew and Linus as this is a general design/policy matter wrt. 
>   memory management. )

[snip]

> Please also realize the difficulties Yinghai has gone through already: 
> converting and generalizing _all_ of the x86 early allocation code to a more 
> generic core kernel approach, with essentially zero interest from _any_ 
> non-x86 person ...

It still seemed to have a lot that was x86-specific - in particular it
seemed to have a lot of code to cope with various mistakes that
firmware might have made in the memory map.  That adds code which is
basically just bloat on architectures where those problems don't
arise.

The fw_memmap.c code also still seemed to be tied to the x86 e820 data
structures and layouts.

> Those early_res patches were posted all over on lkml, it was literally 
> hundreds of difficult patches, and now, months down the line, after we've 
> tested and upstreamed it (with many nasty regressions fixed on x86 during the 
> development of it) you come with a rigid "do it some other way, convert all of 
> x86 over again or else" position.

Well I personally don't mind if x86 uses early_res or whatever other
code in arch/x86 to handle the problems that arise from deficient
firmware.  I just don't see any value in converting powerpc or sparc64
over to using ~2000 lines of early_res/fw_memmap code where the
existing ~500 lines of lmb code is working just fine.

And I don't see the point of moving the x86 e820 stuff into the kernel
directory.  Does any other platform use e820 tables?

> I really wish non-x86 architectures apprecitated (and helped) the core kernel 
> work x86 is doing, because it is subsidizing non-x86 architectures all the 
> time.

We do help with core kernel work.  Coping with deficient x86 firmware
doesn't really feel like core kernel work to me though.

Paul.
--
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/