[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

* Benjamin Herrenschmidt <> wrote:

> On Mon, 2010-03-22 at 14:05 +0100, Ingo Molnar wrote:
> > * 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.
> Then we have no argument. The point is, we object to that fw_memmap/e820
> stuff taking over for non-x86 architectures. We aren't saying that x86
> -must- move to LMB, but if the wish is to have a common implementation in
> generic code accross all archs, -then- we object to it being e820.

Ok, just in case i wasnt clear enough in my first reply (and i guess your mail
means i wasnt): that whole-sale move of e820 into kernel/fw_memmap.c is a
total non-starter as far as i'm concerned.

And i kind of like the 'logical memory block' name - it is more intuitive than
'early_res' (which was always a misnomer IMO, just couldnt find a better name
for it and it stuck with us).

So no arguments from me at all about the code quality aspects - i just wanted
to highlight the huge amount of non-trivial work Yinghai has invested into
this already, with little external help, and that if possible it would be nice
to minimize the upsetting of related x86 code if possible. Please help him out
with more specific suggestions about how the two memory allocation spaces
could be unified best, to serve the needs of all these architectures - if you
have some spare time.



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