* Paul Mackerras <paulus@xxxxxxxxx> 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. > 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. Lets put it this way then: do you see any point in PowerPC making use of a 10+ million lines of code kernel that is being mainly (80%+) financed, developed, tested and deployed by people who care about x86 mostly? If yes then it seems like a pretty damn good deal to me for PowerPC to go beyond its narrow short-term self-interest and work towards generalizations more actively, and even consider touching its 500 lines of lmb code ... I dont know how many times we've accomodated for non-x86 architectures in various pieces of kernel code. Obviously if there's bloat affecting PowerPC then that can be addressed via technical measures. But we really shouldnt leave the slightly incompatible early allocators in place. (we shouldnt have let them get created in the first place, but that is water down the bridge.) Thanks, Ingo -- 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
