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

[Ingo Molnar]

* 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-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/