Re: [PATCH 06/20] early_res: seperate common memmap func from e820.c to fw_memmap.c

[Paul Mackerras <paulus@samba.org>]

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.