[lkml]   [2010]   [Mar]   [22]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [PATCH 06/20] early_res: seperate common memmap func from e820.c to fw_memmap.c

* Paul Mackerras <> 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.)



 \ /
  Last update: 2010-03-22 14:09    [W:0.137 / U:2.132 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site