From: Bernhard Walle <bwalle@suse.de>
To: kexec@lists.infradead.org
Cc: x86@kernel.org, linux-kernel@vger.kernel.org, vgoyal@redhat.com,
Bernhard Walle <bwalle@suse.de>
Subject: [PATCH 1/3] Introduce /proc/firmware_mem
Date: Fri, 20 Jun 2008 17:56:58 +0200 [thread overview]
Message-ID: <1213977420-1555-2-git-send-email-bwalle@suse.de> (raw)
In-Reply-To: <1213977420-1555-1-git-send-email-bwalle@suse.de>
/proc/iomem contains mostly the view of the system about the memory resources.
However, when using kexec, it's necessary to get also the firmware view, i.e.
the original memory map the kernel got passed before applying command line
options like exactmap or mem=<value>. kexec needs both views:
a) When another kernel is booted, then the firmware view is needed. If you
boot your original kernel with mem=3G, then you don't necessarily expect
thew kexec'd kernel also to have a limited amount of memory.
b) When the ELF core headers for kernel dumps are generated, kexec needs the
kernel view about memory resources because it doesn't make sense to dump
memory that never has been used.
The patch only creates the interface and the resource tree. It has to be filled
by architecture code.
Signed-off-by: Bernhard Walle <bwalle@suse.de>
---
include/linux/ioport.h | 1 +
kernel/resource.c | 39 +++++++++++++++++++++++++++++++--------
2 files changed, 32 insertions(+), 8 deletions(-)
diff --git a/include/linux/ioport.h b/include/linux/ioport.h
index c6801bf..4af561a 100644
--- a/include/linux/ioport.h
+++ b/include/linux/ioport.h
@@ -100,6 +100,7 @@ struct resource_list {
/* PC/ISA/whatever - the normal PC address spaces: IO and memory */
extern struct resource ioport_resource;
extern struct resource iomem_resource;
+extern struct resource firmware_mem_resource;
extern int request_resource(struct resource *root, struct resource *new);
extern int release_resource(struct resource *new);
diff --git a/kernel/resource.c b/kernel/resource.c
index 74af2d7..dee58a7 100644
--- a/kernel/resource.c
+++ b/kernel/resource.c
@@ -36,6 +36,15 @@ struct resource iomem_resource = {
};
EXPORT_SYMBOL(iomem_resource);
+struct resource firmware_mem_resource = {
+ .name = "Firmware memory map",
+ .start = 0,
+ .end = -1,
+ .flags = IORESOURCE_MEM,
+};
+EXPORT_SYMBOL(firmware_mem_resource);
+
+
static DEFINE_RWLOCK(resource_lock);
#ifdef CONFIG_PROC_FS
@@ -95,24 +104,30 @@ static const struct seq_operations resource_op = {
.show = r_show,
};
-static int ioports_open(struct inode *inode, struct file *file)
+static int resource_open(struct inode *inode, struct file *file,
+ struct resource *resource)
{
int res = seq_open(file, &resource_op);
if (!res) {
struct seq_file *m = file->private_data;
- m->private = &ioport_resource;
+ m->private = resource;
}
return res;
}
+static int ioports_open(struct inode *inode, struct file *file)
+{
+ return resource_open(inode, file, &ioport_resource);
+}
+
static int iomem_open(struct inode *inode, struct file *file)
{
- int res = seq_open(file, &resource_op);
- if (!res) {
- struct seq_file *m = file->private_data;
- m->private = &iomem_resource;
- }
- return res;
+ return resource_open(inode, file, &iomem_resource);
+}
+
+static int firmware_mem_open(struct inode *inode, struct file *file)
+{
+ return resource_open(inode, file, &firmware_mem_resource);
}
static const struct file_operations proc_ioports_operations = {
@@ -129,10 +144,18 @@ static const struct file_operations proc_iomem_operations = {
.release = seq_release,
};
+static const struct file_operations proc_firmware_mem_operations = {
+ .open = firmware_mem_open,
+ .read = seq_read,
+ .llseek = seq_lseek,
+ .release = seq_release,
+};
+
static int __init ioresources_init(void)
{
proc_create("ioports", 0, NULL, &proc_ioports_operations);
proc_create("iomem", 0, NULL, &proc_iomem_operations);
+ proc_create("firmware_mem", 0, NULL, &proc_firmware_mem_operations);
return 0;
}
__initcall(ioresources_init);
--
1.5.4.5
next prev parent reply other threads:[~2008-06-20 15:57 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-06-20 15:56 Introduce userspace interface for Firmware-provided memory map Bernhard Walle
2008-06-20 15:56 ` Bernhard Walle [this message]
2008-06-20 15:56 ` [PATCH 2/3] Use /proc/firmware_mem for x86 (e820) Bernhard Walle
2008-06-24 18:28 ` Pavel Machek
2008-06-26 8:21 ` Bernhard Walle
2008-06-20 15:57 ` [PATCH 3/3] Limit E820 map when a user-defined memory map is specified Bernhard Walle
2008-06-20 19:45 ` Vivek Goyal
2008-06-20 20:34 ` Yinghai Lu
2008-06-22 19:46 ` Bernhard Walle
2008-06-22 19:56 ` Bernhard Walle
2008-06-22 20:11 ` Yinghai Lu
2008-06-24 14:07 ` Bernhard Walle
2008-06-20 15:58 ` Introduce userspace interface for Firmware-provided memory map Bernhard Walle
2008-06-20 19:42 ` Vivek Goyal
2008-06-20 20:35 ` H. Peter Anvin
2008-06-22 19:59 ` Bernhard Walle
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1213977420-1555-2-git-send-email-bwalle@suse.de \
--to=bwalle@suse.de \
--cc=kexec@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=vgoyal@redhat.com \
--cc=x86@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®