linux.git/include/asm-frv/mem-layout.h, branch master Linux kernel source tree FRV: Move to arch/frv/include/asm/ 2009-04-10T00:48:06+00:00 David Howells dhowells@redhat.com 2009-04-10T00:48:06+00:00 e69cc9278831139660cb99bde52908f145338d77 Move arch headers from include/asm-frv/ to arch/frv/include/asm/. Signed-off-by: David Howells <dhowells@redhat.com> 
Move arch headers from include/asm-frv/ to arch/frv/include/asm/.

Signed-off-by: David Howells <dhowells@redhat.com>
Fix FRV minimum slab/kmalloc alignment 2008-05-28T16:05:28+00:00 David Howells dhowells@redhat.com 2008-05-28T15:49:01+00:00 0a2ce2ffc358da96792d514c1024b72c52be9cc1 > +#define ARCH_KMALLOC_MINALIGN (sizeof(long) * 2) > +#define ARCH_SLAB_MINALIGN (sizeof(long) * 2) This doesn't work if SLAB is selected and slab debugging is enabled as these are passed to the preprocessor, and the preprocessor doesn't understand sizeof. Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org> 
> +#define	ARCH_KMALLOC_MINALIGN		(sizeof(long) * 2)
> +#define	ARCH_SLAB_MINALIGN		(sizeof(long) * 2)

This doesn't work if SLAB is selected and slab debugging is enabled as
these are passed to the preprocessor, and the preprocessor doesn't
understand sizeof.

Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
FRV: Specify the minimum slab/kmalloc alignment 2008-05-28T14:59:06+00:00 David Howells dhowells@redhat.com 2008-05-28T14:36:34+00:00 dc1d60a014aa9614518f9856ff661716d0969ffd Specify the minimum slab/kmalloc alignment to be 8 bytes. This fixes a crash when SLOB is selected as the memory allocator. The FRV arch needs this so that it can use the load- and store-double instructions without faulting. By default SLOB sets the minimum to be 4 bytes. Signed-off-by: David Howells <dhowells@redhat.com> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org> 
Specify the minimum slab/kmalloc alignment to be 8 bytes.  This fixes a
crash when SLOB is selected as the memory allocator.  The FRV arch needs
this so that it can use the load- and store-double instructions without
faulting.  By default SLOB sets the minimum to be 4 bytes.

Signed-off-by: David Howells <dhowells@redhat.com>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
FRV: Move STACK_TOP_MAX up [try #2] 2008-04-10T20:41:28+00:00 David Howells dhowells@redhat.com 2008-04-10T15:10:50+00:00 0c93d8e4d342b1b5cda1037f2527fcf443c80fbc Move STACK_TOP_MAX up so that we don't try moving the stack above it as that causes setup_arg_pages() to malfunction. Signed-off-by: David Howells <dhowells@redhat.com> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org> 
Move STACK_TOP_MAX up so that we don't try moving the stack above it as that
causes setup_arg_pages() to malfunction.

Signed-off-by: David Howells <dhowells@redhat.com>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
move frv docs one level up 2008-02-03T13:54:28+00:00 Adrian Bunk bunk@kernel.org 2008-02-03T13:54:28+00:00 0868ff7a4215f9244037b63a2952761cbe196a07 My first guess for "fujitsu" was it might be related to the fujitsu-laptop.c driver... Move the frv directory one level up since frv is the name of the architecture in the Linux kernel. Signed-off-by: Adrian Bunk <bunk@kernel.org> 
My first guess for "fujitsu" was it might be related to the
fujitsu-laptop.c driver...

Move the frv directory one level up since frv is the name of the
architecture in the Linux kernel.

Signed-off-by: Adrian Bunk <bunk@kernel.org>
arch: personality independent stack top 2007-07-19T17:04:45+00:00 Peter Zijlstra a.p.zijlstra@chello.nl 2007-07-19T08:48:14+00:00 b111757c50ee30dad162192df6168e270a90c252 New arch macro STACK_TOP_MAX it gives the larges valid stack address for the architecture in question. It differs from STACK_TOP in that it will not distinguish between personalities but will always return the largest possible address. This is used to create the initial stack on execve, which we will move down to the proper location once the binfmt code has figured out where that is. Signed-off-by: Peter Zijlstra <a.p.zijlstra@chello.nl> Signed-off-by: Ollie Wild <aaw@google.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org> 
New arch macro STACK_TOP_MAX it gives the larges valid stack address for the
architecture in question.

It differs from STACK_TOP in that it will not distinguish between
personalities but will always return the largest possible address.

This is used to create the initial stack on execve, which we will move down to
the proper location once the binfmt code has figured out where that is.

Signed-off-by: Peter Zijlstra <a.p.zijlstra@chello.nl>
Signed-off-by: Ollie Wild <aaw@google.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Linux-2.6.12-rc2 2005-04-16T22:20:36+00:00 Linus Torvalds torvalds@ppc970.osdl.org 2005-04-16T22:20:36+00:00 1da177e4c3f41524e886b7f1b8a0c1fc7321cac2 Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip! 
Initial git repository build. I'm not bothering with the full history,
even though we have it. We can create a separate "historical" git
archive of that later if we want to, and in the meantime it's about
3.2GB when imported into git - space that would just make the early
git days unnecessarily complicated, when we don't have a lot of good
infrastructure for it.

Let it rip!