linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
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


             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).