This patch tries to unify the behaviour of i386 and x86-64 when parsing
the memory (mem/memmap) parameter of the kernel command line:On i386, the view was limited (i.e. the actual view was presented).
On x86-64, the view was full (i.e. the BIOS view was presented).This patch moves the limit_regions() function and the print_memory_map()
function to a new file e820.c, shared between the two x86 flavours. Then
it adds calls to limit_regions() in 64 bit code.I gave the patch a bit testing. However, it's not for merging, it's just
to get early feedback to see if that goes into the right direction.Signed-off-by: Bernhard Walle <bwalle@suse.de>
---
arch/x86/kernel/Makefile | 2 -
arch/x86/kernel/e820.c | 75 +++++++++++++++++++++++++++++++++++++++++++++
arch/x86/kernel/e820_32.c | 60 +-----------------------------------
arch/x86/kernel/e820_64.c | 4 ++
arch/x86/kernel/setup_32.c | 4 +-
include/asm-x86/e820.h | 4 ++
6 files changed, 88 insertions(+), 61 deletions(-)--- a/arch/x86/kernel/Makefile
+++ b/arch/x86/kernel/Makefile
@@ -22,7 +22,7 @@ obj-y += setup_$(BITS).o i8259_$(BITS)
obj-$(CONFIG_X86_32) += sys_i386_32.o i386_ksyms_32.o
obj-$(CONFIG_X86_64) += sys_x86_64.o x8664_ksyms_64.o
obj-$(CONFIG_X86_64) += syscall_64.o vsyscall_64.o setup64.o
-obj-y += bootflag.o e820_$(BITS).o
+obj-y += bootflag.o e820_$(BITS).o e820.o
obj-y += pci-dma.o quirks.o i8237.o topology.o kdebugfs.o
obj-y += alternative.o i8253.o pci-nommu.o
obj-$(CONFIG_X86_64) += bugs_64.o
--- /dev/null
+++ b/arch/x86/kernel/e820.c
@@ -0,0 +1,75 @@
+#include <linux/kernel.h>
+#include <linux/types.h>
+#include <linux/init.h>
+#include <linux/bootmem.h>
+#include <linux/ioport.h>
+#include <linux/string.h>
+#include <linux/kexec.h>
+#include <linux/module.h>
+#include <linux/mm.h>
+#include <linux/pfn.h>
+#include <linux/uaccess.h>
+#include <linux/suspend.h>
+
+#inc...
can you check tip/master about that e820 merge?
http://people.redhat.com/mingo/tip.git/readme.txt
it made 32bit using e820_register_active_region...and limit_region in
32bit is remove.YH
--
I would like to have consistent behavior of /proc/iomem across i386
and x86_64, so this sounds like right direction to me.Also I would like to have another interface (say /proc/iomem_kernel)which
actually gets modified based on the user specified options. So effectively we
can have both the views. BIOS view and user defined view.As discussed on kexec mailing list, it helps kexec and kdump operation.
In the case of kexec, we want to know the actual resources present in
the system so that new kernel can see it (Irrespective of the fact
what first kernel was actually using).In case of kdump, we want to see truncated view so that we don't end
up capturing the contents of memory not being used by kernel.Thanks
Vivek
--
Yes, of course, I just don't have time to work full-time on that, so be
a bit patient. :)Bernhard
--
Bernhard Walle, SUSE LINUX Products GmbH, Architecture Development
--
| Greg Kroah-Hartman | [PATCH 002/196] Chinese: rephrase English introduction in HOWTO |
| Tarkan Erimer | Re: Dual-Licensing Linux Kernel with GPL V2 and GPL V3 |
| Andrew Morton | Re: -mm merge plans for 2.6.23 -- sys_fallocate |
| Greg KH | Re: [AppArmor 39/45] AppArmor: Profile loading and manipulation, pathname matching |
git: | |
| Gerrit Renker | [PATCH 03/37] dccp: List management for new feature negotiation |
| Arjan van de Ven | Re: [GIT]: Networking |
| Jarek Poplawski | Re: [PATCH] pkt_sched: Destroy gen estimators under rtnl_lock(). |
| Jarek Poplawski | Re: [BUG] New Kernel Bugs |
