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>
Cc: Kernel Mailing List <linux-kernel@vger.kernel.org>
Subject: Re: Linux 2.5.75
Date: Fri, 11 Jul 2003 00:05:46 +0100	[thread overview]
Message-ID: <20030711000546.B20214@flint.arm.linux.org.uk> (raw)
In-Reply-To: <Pine.LNX.4.44.0307101512350.4757-100000@home.osdl.org>; from torvalds@osdl.org on Thu, Jul 10, 2003 at 03:26:09PM -0700

On Thu, Jul 10, 2003 at 03:26:09PM -0700, Linus Torvalds wrote:
> On Thu, 10 Jul 2003, Russell King wrote:
> > 
> > Well, only two words from me.  Oh Shit.
> 
> Hey, this is already much later than it should have been, so it's not as
> if this is a huge surprise.

Absolutely no surprise.  In any case, the long development cycle isn't
what ARM stuff needs.

For example, during 2.3, people only started serious merging with myself
of the StrongARM SoC code towards the end of 2.3 when it became important
to them for 2.4.  That caused the serial layer rewrite around 2.4.2 time
and later spawned the cpufreq project, both of which has been maintained
ever since.  Now that StrongARM SoC has been end of life'd by Intel, most
of the work which went into 2.5 is wasted because probably no one will
ever use it.

A fine example of this was what happened with the touchscreen stuff
(thank god we got the input layer in 2.5.)

I see the same thing happening to the Intel PXA (Xscale stuff.)
Virtually the whole of the ARM community is working on 2.4 for Xscale
because that's the current stable kernel.  They're not interested in 2.6
until 2.6 actually comes out.  At this point, everyone will want their
drivers to work on that kernel.  Of course, 2.8 will be too late.

And then yours truely then ends up with loads of crap patches and we
start the process again.

The major problem is that embedded developers only care about what
works for them and what they can provide to their customers.  Once
that's done, they don't have any interest in cleaning stuff up nor
feeding obvious bug fixes back up.

> > The 2.5.70 ARM patch currently looks like this:
> 
> We can sort it out later. Obviously, clearly arm-specific patches (ie
> stuff in arch/arm and include/asm-arm) I wouldn't mind per se, but I'd
> rather hold back on even those just to make the patches and the changlogs
> not be mixed up with the "main bugfixes".

I've still got to sort out the module space and /proc/kcore - we allocate
the module space between TASK_SIZE and PAGE_OFFSET, which needs vmalloc
to be aware that entries on the vmlist may cover two allocatable areas.
Maybe this has changed, I haven't had time to look into this.  This is
probably the main reason why stock 2.5 (since Rusty's module changes
went in, recent) has never built for ARM.

I don't think the kclist stuff really fits this for me - it doesn't
allow me to do allocations off it, and I don't want yet another
list for modules.  I guess I'm going to stick with my current approach
of having two memory spaces in the vmlist.  (see patch).

> We've never had a first stable release that has all architectures
> up-to-date, and I'm not planning on changing that for 2.6.x. This is _not_
> the time to try to make my tree build on arm (or other architectures
> either), considering that my tree hasn't been the main ARM tree for a long 
> time.

Hasn't ever, I'm afraid.  I can't think of any stock kernel which has
been usable, let alone been compilable for ARM.  Which, IMO, is a pretty
sorry statement to make.


--- 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-07-10 22:51 UTC|newest]

Thread overview: 33+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2003-07-10 21:14 Linux 2.5.75 Linus Torvalds
2003-07-10 21:35 ` Russell King
2003-07-10 22:26   ` Linus Torvalds
2003-07-10 23:05     ` Russell King [this message]
2003-07-10 23:25       ` Linus Torvalds
2003-07-11 19:59       ` Horst von Brand
2003-07-10 23:30 ` Felipe Alfaro Solana
2003-07-10 23:38   ` Linus Torvalds
2003-07-10 23:46     ` Davide Libenzi
2003-07-10 23:40   ` Robert Love
2003-07-11  0:24     ` Diego Calleja García
2003-07-11  0:49       ` Wade
2003-07-11  7:09 ` Benjamin Herrenschmidt
2003-07-11 10:57 ` Linux 2.5.75 - still can't load aha152x (isapnp) => OOPS schmurtz
2003-07-11 17:53   ` Andrew Morton
2003-07-11 18:04     ` James Bottomley
2003-07-11 18:45     ` schmurtz
2003-07-11 12:30 ` incbin (was: Re: Linux 2.5.75) Geert Uytterhoeven
2003-07-11 12:32   ` Geert Uytterhoeven
2003-07-11 15:46 ` Linux 2.5.75 Oliver Pitzeier
2003-07-11 15:52 ` Linux 2.5.75 (compile statistics) John Cherry
2003-07-12 13:50 ` AMD 53C974 based SCSI adapter (was: Linux 2.5.75) Matthias Andree
     [not found] <20030710223548.A20214@flint.arm.linux.org.uk.suse.lists.linux.kernel>
     [not found] ` <Pine.LNX.4.44.0307101512350.4757-100000@home.osdl.org.suse.lists.linux.kernel>
2003-07-10 23:55   ` Linux 2.5.75 Andi Kleen
2003-07-11  0:12     ` Linus Torvalds
2003-07-11  0:55       ` Paul Mackerras
2003-07-11  8:42       ` Christoph Hellwig
2003-07-11 10:27         ` Lars Marowsky-Bree
2003-07-11 10:39           ` Christoph Hellwig
2003-07-11 16:52           ` Linus Torvalds
2003-07-11 17:03             ` Arjan van de Ven
2003-07-12 19:20               ` Horst von Brand
2003-07-12 23:17                 ` Jeff Garzik
     [not found] <7TEe.Bz.21@gated-at.bofh.it>
     [not found] ` <7TNS.Kc.9@gated-at.bofh.it>
2003-07-11 21:33   ` Arnd Bergmann

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=20030711000546.B20214@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).