From: Russell King <rmk@arm.linux.org.uk>
To: Linus Torvalds <torvalds@osdl.org>,
Linux Kernel List <linux-kernel@vger.kernel.org>
Subject: [PATCH] Make modules work in Linus' tree on ARM
Date: Thu, 14 Aug 2003 13:08:10 +0100 [thread overview]
Message-ID: <20030814130810.A332@flint.arm.linux.org.uk> (raw)
This patch allows modules to work in Linus' tree for ARM, and is the one
thing which prevents Linus' tree from building for any ARM machine.
After reviewing the /proc/kcore and kclist issues, I've decided that I'm
no longer prepared to even _think_ about supporting /proc/kcore on ARM -
it just gets too ugly, and adds too much code to make it worth the effort,
the time or the energy to implement a solution to that problem. This is
especially true since most people use kgdb or similar rather than
/proc/kcore anyway. /proc/kcore is a "wouldn't it be nice" feature.
The reasons that I'm going with this solution rather than fixing
/proc/kcore is that:
- to add a kclist entry for each module would mean hacking the kclist
structure into vm_struct's ->page pointer with disgusting hacks.
I think we can all agree that this isn't the way to go. The
alternative is to create Yet Another Memory Allocator, and this
isn't something I want to see in what is now an embedded architecture.
- we'd need to find some way to dynamically reserve the virtual mapped
memory regions for the kernel direct mapped RAM. Since ARM uses a
generic memory initialisation implementation which handles contiguous
and discontiguous memory, it doesn't lend itself well to the kclist
approach, and I'm not about to add extra callbacks from init/main.c
(so we have kmalloc available) just to support this.
If someone _else_ wants to put the effort into fixing ARM modules to work
nicely with /proc/kcore, be my guest - I'm just no longer interested in
this problem space.
Maybe in 2.7 a generic "reserve an area of memory in this region"
function like __get_vm_area below is in order?
Therefore, I'm providing a patch which adds the necessary changes to the
core kernel code to make the current modules solution work for ARM.
Please merge.
--- orig/mm/vmalloc.c Tue May 27 10:05:48 2003
+++ linux/mm/vmalloc.c Tue May 27 10:14:45 2003
@@ -178,21 +178,11 @@
return err;
}
-
-/**
- * get_vm_area - reserve a contingous kernel virtual area
- *
- * @size: size of the area
- * @flags: %VM_IOREMAP for I/O mappings or VM_ALLOC
- *
- * Search an area of @size in the kernel virtual mapping area,
- * and reserved it for out purposes. Returns the area descriptor
- * on success or %NULL on failure.
- */
-struct vm_struct *get_vm_area(unsigned long size, unsigned long flags)
+struct vm_struct *__get_vm_area(unsigned long size, unsigned long flags,
+ unsigned long start, unsigned long end)
{
struct vm_struct **p, *tmp, *area;
- unsigned long addr = VMALLOC_START;
+ unsigned long addr = start;
area = kmalloc(sizeof(*area), GFP_KERNEL);
if (unlikely(!area))
@@ -209,12 +199,14 @@
write_lock(&vmlist_lock);
for (p = &vmlist; (tmp = *p) ;p = &tmp->next) {
+ if ((unsigned long)tmp->addr < addr)
+ continue;
if ((size + addr) < addr)
goto out;
if (size + addr <= (unsigned long)tmp->addr)
goto found;
addr = tmp->size + (unsigned long)tmp->addr;
- if (addr > VMALLOC_END-size)
+ if (addr > end - size)
goto out;
}
@@ -239,6 +231,21 @@
}
/**
+ * get_vm_area - reserve a contingous kernel virtual area
+ *
+ * @size: size of the area
+ * @flags: %VM_IOREMAP for I/O mappings or VM_ALLOC
+ *
+ * Search an area of @size in the kernel virtual mapping area,
+ * and reserved it for out purposes. Returns the area descriptor
+ * on success or %NULL on failure.
+ */
+struct vm_struct *get_vm_area(unsigned long size, unsigned long flags)
+{
+ return __get_vm_area(size, flags, VMALLOC_START, VMALLOC_END);
+}
+
+/**
* remove_vm_area - find and remove a contingous kernel virtual area
*
* @addr: base address
--
Russell King (rmk@arm.linux.org.uk) The developer of ARM Linux
http://www.arm.linux.org.uk/personal/aboutme.html
next reply other threads:[~2003-08-14 12:09 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2003-08-14 12:08 Russell King [this message]
2003-08-14 16:19 ` [PATCH] Make modules work in Linus' tree on ARM Linus Torvalds
2003-08-14 16:32 ` Russell King
2003-09-17 9:23 ` Russell King
2003-08-14 16:47 ` Alan Cox
2003-08-14 16:55 ` John Levon
2003-08-14 17:06 ` Alan Cox
2003-08-14 17:19 ` Linus Torvalds
2003-08-14 17:14 ` Linus Torvalds
2003-08-14 17:30 ` John Levon
2003-08-14 19:18 ` [PATCH] Export pointer size in oprofilefs John Levon
2003-08-14 17:24 ` [PATCH] Make modules work in Linus' tree on ARM Russell King
2003-08-14 20:12 ` Eli Carter
2003-08-14 20:42 ` Russell King
2003-08-18 19:27 ` Daniel Jacobowitz
2003-08-14 17:16 John Bradford
2003-08-14 17:42 Luck, Tony
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=20030814130810.A332@flint.arm.linux.org.uk \
--to=rmk@arm.linux.org.uk \
--cc=linux-kernel@vger.kernel.org \
--cc=torvalds@osdl.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;
as well as URLs for NNTP newsgroup(s).