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-arch" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html