early_res: seperate common memmap func from e820.c to fw_memmap.c
in [Kernel]
|
Prev: [PATCH 4/4] x86: make e820 to be initdata
Next: early_res: seperate common memmap func from e820.c to fw_memmap.c
From: Russell King on 10 Mar 2010 17:00 On Wed, Mar 10, 2010 at 01:24:26PM -0800, Yinghai Lu wrote: > +/* How much should we pad RAM ending depending on where it is? */ > +static unsigned long __init ram_alignment(resource_size_t pos) > +{ > + unsigned long mb = pos >> 20; > + > + /* To 64kB in the first megabyte */ > + if (!mb) > + return 64*1024; > + > + /* To 1MB in the first 16MB */ > + if (mb < 16) > + return 1024*1024; > + > + /* To 64MB for anything above that */ > + return 64*1024*1024; > +} This doesn't make sense for generic code. 1. All architectures do not have RAM starting at physical address 0. 2. What about architectures which have relatively little memory (maybe 16MB total) split into four chunks of 4MB spaced at 512MB ? Other comments: 1. It doesn't support mem=size(a)base, which is used extensively on ARM. 2. How does memory get allocated for creating things like page tables? Currently, bootmem supports ARM very well with support for flatmem, sparsemem and discontigmem models (the latter being deprecated). Can this code support all three models? Where are patches 1 to 4? Lastly, why exactly is bootmem being eliminated? Bootmem offers more flexible functionality than this e820 code appears at first read-through seems to. -- Russell King Linux kernel 2.6 ARM Linux - http://www.arm.linux.org.uk/ maintainer of: -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ |