* [PATCH] m68k/m68knommu: merge MMU and non-MMU string.h
@ 2010-09-07 4:52 Greg Ungerer
2010-09-07 20:35 ` Geert Uytterhoeven
2010-09-13 18:22 ` Geert Uytterhoeven
0 siblings, 2 replies; 14+ messages in thread
From: Greg Ungerer @ 2010-09-07 4:52 UTC (permalink / raw)
To: linux-m68k; +Cc: gerg
m68k/m68knommu: merge MMU and non-MMU string.h
The MMU and non-MMU string.h varients (string_no.h and string_mm.h)
and almost the same. Switch to using the string_mm.h one, merging
in the necessary ColdFire support.
Signed-off-by: Greg Ungerer <gerg@uclinux.org>
---
arch/m68k/include/asm/{string_mm.h => string.h} | 16 ++--
arch/m68k/include/asm/string_no.h | 126 -----------------------
2 files changed, 9 insertions(+), 133 deletions(-)
rename arch/m68k/include/asm/{string_mm.h => string.h} (98%)
delete mode 100644 arch/m68k/include/asm/string_no.h
diff --git a/arch/m68k/include/asm/string_mm.h b/arch/m68k/include/asm/string.h
similarity index 98%
rename from arch/m68k/include/asm/string_mm.h
rename to arch/m68k/include/asm/string.h
index 2eb7df1..2936dda 100644
--- a/arch/m68k/include/asm/string_mm.h
+++ b/arch/m68k/include/asm/string.h
@@ -93,6 +93,7 @@ static inline char *strchr(const char *s, int c)
return (char *)s - 1;
}
+#ifndef CONFIG_COLDFIRE
#define __HAVE_ARCH_STRCMP
static inline int strcmp(const char *cs, const char *ct)
{
@@ -111,6 +112,14 @@ static inline int strcmp(const char *cs, const char *ct)
return res;
}
+#define __HAVE_ARCH_MEMMOVE
+extern void *memmove(void *, const void *, __kernel_size_t);
+
+#define __HAVE_ARCH_MEMCMP
+extern int memcmp(const void *, const void *, __kernel_size_t);
+#define memcmp(d, s, n) __builtin_memcmp(d, s, n)
+#endif /* CONFIG_COLDFIRE */
+
#define __HAVE_ARCH_MEMSET
extern void *memset(void *, int, __kernel_size_t);
#define memset(d, c, n) __builtin_memset(d, c, n)
@@ -119,13 +128,6 @@ extern void *memset(void *, int, __kernel_size_t);
extern void *memcpy(void *, const void *, __kernel_size_t);
#define memcpy(d, s, n) __builtin_memcpy(d, s, n)
-#define __HAVE_ARCH_MEMMOVE
-extern void *memmove(void *, const void *, __kernel_size_t);
-
-#define __HAVE_ARCH_MEMCMP
-extern int memcmp(const void *, const void *, __kernel_size_t);
-#define memcmp(d, s, n) __builtin_memcmp(d, s, n)
-
#endif
#endif /* _M68K_STRING_H_ */
diff --git a/arch/m68k/include/asm/string_no.h b/arch/m68k/include/asm/string_no.h
deleted file mode 100644
index af09e17..0000000
--- a/arch/m68k/include/asm/string_no.h
+++ /dev/null
@@ -1,126 +0,0 @@
-#ifndef _M68KNOMMU_STRING_H_
-#define _M68KNOMMU_STRING_H_
-
-#ifdef __KERNEL__ /* only set these up for kernel code */
-
-#include <asm/setup.h>
-#include <asm/page.h>
-
-#define __HAVE_ARCH_STRCPY
-static inline char * strcpy(char * dest,const char *src)
-{
- char *xdest = dest;
-
- __asm__ __volatile__
- ("1:\tmoveb %1@+,%0@+\n\t"
- "jne 1b"
- : "=a" (dest), "=a" (src)
- : "0" (dest), "1" (src) : "memory");
- return xdest;
-}
-
-#define __HAVE_ARCH_STRNCPY
-static inline char * strncpy(char *dest, const char *src, size_t n)
-{
- char *xdest = dest;
-
- if (n == 0)
- return xdest;
-
- __asm__ __volatile__
- ("1:\tmoveb %1@+,%0@+\n\t"
- "jeq 2f\n\t"
- "subql #1,%2\n\t"
- "jne 1b\n\t"
- "2:"
- : "=a" (dest), "=a" (src), "=d" (n)
- : "0" (dest), "1" (src), "2" (n)
- : "memory");
- return xdest;
-}
-
-
-#ifndef CONFIG_COLDFIRE
-
-#define __HAVE_ARCH_STRCMP
-static inline int strcmp(const char * cs,const char * ct)
-{
- char __res;
-
- __asm__
- ("1:\tmoveb %0@+,%2\n\t" /* get *cs */
- "cmpb %1@+,%2\n\t" /* compare a byte */
- "jne 2f\n\t" /* not equal, break out */
- "tstb %2\n\t" /* at end of cs? */
- "jne 1b\n\t" /* no, keep going */
- "jra 3f\n\t" /* strings are equal */
- "2:\tsubb %1@-,%2\n\t" /* *cs - *ct */
- "3:"
- : "=a" (cs), "=a" (ct), "=d" (__res)
- : "0" (cs), "1" (ct));
-
- return __res;
-}
-
-#define __HAVE_ARCH_STRNCMP
-static inline int strncmp(const char * cs,const char * ct,size_t count)
-{
- char __res;
-
- if (!count)
- return 0;
- __asm__
- ("1:\tmovb %0@+,%3\n\t" /* get *cs */
- "cmpb %1@+,%3\n\t" /* compare a byte */
- "jne 3f\n\t" /* not equal, break out */
- "tstb %3\n\t" /* at end of cs? */
- "jeq 4f\n\t" /* yes, all done */
- "subql #1,%2\n\t" /* no, adjust count */
- "jne 1b\n\t" /* more to do, keep going */
- "2:\tmoveq #0,%3\n\t" /* strings are equal */
- "jra 4f\n\t"
- "3:\tsubb %1@-,%3\n\t" /* *cs - *ct */
- "4:"
- : "=a" (cs), "=a" (ct), "=d" (count), "=d" (__res)
- : "0" (cs), "1" (ct), "2" (count));
- return __res;
-}
-
-#endif /* CONFIG_COLDFIRE */
-
-#define __HAVE_ARCH_MEMSET
-extern void * memset(void * s, int c, size_t count);
-
-#define __HAVE_ARCH_MEMCPY
-extern void * memcpy(void *d, const void *s, size_t count);
-
-#else /* KERNEL */
-
-/*
- * let user libraries deal with these,
- * IMHO the kernel has no place defining these functions for user apps
- */
-
-#define __HAVE_ARCH_STRCPY 1
-#define __HAVE_ARCH_STRNCPY 1
-#define __HAVE_ARCH_STRCAT 1
-#define __HAVE_ARCH_STRNCAT 1
-#define __HAVE_ARCH_STRCMP 1
-#define __HAVE_ARCH_STRNCMP 1
-#define __HAVE_ARCH_STRNICMP 1
-#define __HAVE_ARCH_STRCHR 1
-#define __HAVE_ARCH_STRRCHR 1
-#define __HAVE_ARCH_STRSTR 1
-#define __HAVE_ARCH_STRLEN 1
-#define __HAVE_ARCH_STRNLEN 1
-#define __HAVE_ARCH_MEMSET 1
-#define __HAVE_ARCH_MEMCPY 1
-#define __HAVE_ARCH_MEMMOVE 1
-#define __HAVE_ARCH_MEMSCAN 1
-#define __HAVE_ARCH_MEMCMP 1
-#define __HAVE_ARCH_MEMCHR 1
-#define __HAVE_ARCH_STRTOK 1
-
-#endif /* KERNEL */
-
-#endif /* _M68K_STRING_H_ */
--
^ permalink raw reply related [flat|nested] 14+ messages in thread
* Re: [PATCH] m68k/m68knommu: merge MMU and non-MMU string.h
2010-09-07 4:52 [PATCH] m68k/m68knommu: merge MMU and non-MMU string.h Greg Ungerer
@ 2010-09-07 20:35 ` Geert Uytterhoeven
2010-09-07 20:45 ` Geert Uytterhoeven
2010-09-08 11:43 ` Greg Ungerer
2010-09-13 18:22 ` Geert Uytterhoeven
1 sibling, 2 replies; 14+ messages in thread
From: Geert Uytterhoeven @ 2010-09-07 20:35 UTC (permalink / raw)
To: Greg Ungerer; +Cc: linux-m68k, gerg
On Tue, Sep 7, 2010 at 06:52, Greg Ungerer <gerg@snapgear.com> wrote:
> m68k/m68knommu: merge MMU and non-MMU string.h
>
> The MMU and non-MMU string.h varients (string_no.h and string_mm.h)
> and almost the same. Switch to using the string_mm.h one, merging
> in the necessary ColdFire support.
>
> Signed-off-by: Greg Ungerer <gerg@uclinux.org>
> ---
> arch/m68k/include/asm/{string_mm.h => string.h} | 16 ++--
> arch/m68k/include/asm/string_no.h | 126 -----------------------
> 2 files changed, 9 insertions(+), 133 deletions(-)
> rename arch/m68k/include/asm/{string_mm.h => string.h} (98%)
> delete mode 100644 arch/m68k/include/asm/string_no.h
>
> diff --git a/arch/m68k/include/asm/string_mm.h b/arch/m68k/include/asm/string.h
> similarity index 98%
> rename from arch/m68k/include/asm/string_mm.h
> rename to arch/m68k/include/asm/string.h
> index 2eb7df1..2936dda 100644
> --- a/arch/m68k/include/asm/string_mm.h
> +++ b/arch/m68k/include/asm/string.h
Thanks!
How do you apply such renaming patches? I thought git can handle them, but
`git am' just says:
| Applying: m68k/m68knommu: merge MMU and non-MMU string.h
| error: arch/m68k/include/asm/string.h: already exists in index
| Patch failed at 0001 m68k/m68knommu: merge MMU and non-MMU string.h
| When you have resolved this problem run "git am --resolved".
| If you would prefer to skip this patch, instead run "git am --skip".
| To restore the original branch and stop patching run "git am --abort".
And according to "git status" no files have conflicts??
I ended up editing the patch to modify string_mm.h, and did the rename manually.
I applied all patches (except the hardirq one) and am currently
building my test kernels.
Now I see:
| arch/m68k/kernel/entry.S: Assembler messages:
| arch/m68k/kernel/entry.S:56: Error: can't resolve `0' {*ABS*
section} - `THREAD_SIZE' {*UND* section}
| arch/m68k/kernel/entry.S:64: Error: can't resolve `0' {*UND*
section} - `THREAD_SIZE' {*UND* section}
| arch/m68k/kernel/entry.S:119: Error: can't resolve `0' {*UND*
section} - `THREAD_SIZE' {*UND* section}
| arch/m68k/kernel/entry.S:203: Error: can't resolve `0' {*UND*
section} - `THREAD_SIZE' {*UND* section}
| arch/m68k/kernel/entry.S:236: Error: can't resolve `0' {*UND*
section} - `THREAD_SIZE' {*UND* section}
| arch/m68k/kernel/entry.S:257: Error: can't resolve `0' {*UND*
section} - `THREAD_SIZE' {*UND* section}
this is expanded from `GET_CURRENT'.
continuing...
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [PATCH] m68k/m68knommu: merge MMU and non-MMU string.h
2010-09-07 20:35 ` Geert Uytterhoeven
@ 2010-09-07 20:45 ` Geert Uytterhoeven
2010-09-08 11:43 ` Greg Ungerer
1 sibling, 0 replies; 14+ messages in thread
From: Geert Uytterhoeven @ 2010-09-07 20:45 UTC (permalink / raw)
To: Greg Ungerer; +Cc: linux-m68k, gerg
On Tue, Sep 7, 2010 at 22:35, Geert Uytterhoeven <geert@linux-m68k.org> wrote:
> I applied all patches (except the hardirq one) and am currently
> building my test kernels.
> Now I see:
>
> | arch/m68k/kernel/entry.S: Assembler messages:
> | arch/m68k/kernel/entry.S:56: Error: can't resolve `0' {*ABS* section} - `THREAD_SIZE' {*UND* section}
> | arch/m68k/kernel/entry.S:64: Error: can't resolve `0' {*UND* section} - `THREAD_SIZE' {*UND* section}
> | arch/m68k/kernel/entry.S:119: Error: can't resolve `0' {*UND* section} - `THREAD_SIZE' {*UND* section}
> | arch/m68k/kernel/entry.S:203: Error: can't resolve `0' {*UND* section} - `THREAD_SIZE' {*UND* section}
> | arch/m68k/kernel/entry.S:236: Error: can't resolve `0' {*UND* section} - `THREAD_SIZE' {*UND* section}
> | arch/m68k/kernel/entry.S:257: Error: can't resolve `0' {*UND* section} - `THREAD_SIZE' {*UND* section}
>
> this is expanded from `GET_CURRENT'.
>
> continuing...
Several of the *.S files now need to include <asm/thread_info.h>, I guess.
Will try to look more into it tomorrow, if no one beats me to it.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [PATCH] m68k/m68knommu: merge MMU and non-MMU string.h
2010-09-07 20:35 ` Geert Uytterhoeven
2010-09-07 20:45 ` Geert Uytterhoeven
@ 2010-09-08 11:43 ` Greg Ungerer
2010-09-08 12:01 ` Andreas Schwab
2010-09-09 19:14 ` Geert Uytterhoeven
1 sibling, 2 replies; 14+ messages in thread
From: Greg Ungerer @ 2010-09-08 11:43 UTC (permalink / raw)
To: Geert Uytterhoeven; +Cc: linux-m68k, gerg
Hi Geert,
On 08/09/10 06:35, Geert Uytterhoeven wrote:
> On Tue, Sep 7, 2010 at 06:52, Greg Ungerer<gerg@snapgear.com> wrote:
>> m68k/m68knommu: merge MMU and non-MMU string.h
>>
>> The MMU and non-MMU string.h varients (string_no.h and string_mm.h)
>> and almost the same. Switch to using the string_mm.h one, merging
>> in the necessary ColdFire support.
>>
>> Signed-off-by: Greg Ungerer<gerg@uclinux.org>
>> ---
>> arch/m68k/include/asm/{string_mm.h => string.h} | 16 ++--
>> arch/m68k/include/asm/string_no.h | 126 -----------------------
>> 2 files changed, 9 insertions(+), 133 deletions(-)
>> rename arch/m68k/include/asm/{string_mm.h => string.h} (98%)
>> delete mode 100644 arch/m68k/include/asm/string_no.h
>>
>> diff --git a/arch/m68k/include/asm/string_mm.h b/arch/m68k/include/asm/string.h
>> similarity index 98%
>> rename from arch/m68k/include/asm/string_mm.h
>> rename to arch/m68k/include/asm/string.h
>> index 2eb7df1..2936dda 100644
>> --- a/arch/m68k/include/asm/string_mm.h
>> +++ b/arch/m68k/include/asm/string.h
>
> Thanks!
>
> How do you apply such renaming patches? I thought git can handle them, but
> `git am' just says:
Hmm, good question. Maybe I should generate stand alone patches
without gits rename detection turned on?
> | Applying: m68k/m68knommu: merge MMU and non-MMU string.h
> | error: arch/m68k/include/asm/string.h: already exists in index
> | Patch failed at 0001 m68k/m68knommu: merge MMU and non-MMU string.h
> | When you have resolved this problem run "git am --resolved".
> | If you would prefer to skip this patch, instead run "git am --skip".
> | To restore the original branch and stop patching run "git am --abort".
>
> And according to "git status" no files have conflicts??
>
> I ended up editing the patch to modify string_mm.h, and did the rename manually.
>
> I applied all patches (except the hardirq one) and am currently
> building my test kernels.
Thanks!
> Now I see:
>
> | arch/m68k/kernel/entry.S: Assembler messages:
> | arch/m68k/kernel/entry.S:56: Error: can't resolve `0' {*ABS*
> section} - `THREAD_SIZE' {*UND* section}
> | arch/m68k/kernel/entry.S:64: Error: can't resolve `0' {*UND*
> section} - `THREAD_SIZE' {*UND* section}
> | arch/m68k/kernel/entry.S:119: Error: can't resolve `0' {*UND*
> section} - `THREAD_SIZE' {*UND* section}
> | arch/m68k/kernel/entry.S:203: Error: can't resolve `0' {*UND*
> section} - `THREAD_SIZE' {*UND* section}
> | arch/m68k/kernel/entry.S:236: Error: can't resolve `0' {*UND*
> section} - `THREAD_SIZE' {*UND* section}
> | arch/m68k/kernel/entry.S:257: Error: can't resolve `0' {*UND*
> section} - `THREAD_SIZE' {*UND* section}
>
> this is expanded from `GET_CURRENT'.
Just a thought, is it enough to include thread_info.h inside entry_mm.h?
Regards
Greg
> Gr{oetje,eeting}s,
>
> Geert
>
> --
> Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
>
> In personal conversations with technical people, I call myself a hacker. But
> when I'm talking to journalists I just say "programmer" or something like that.
> -- Linus Torvalds
>
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [PATCH] m68k/m68knommu: merge MMU and non-MMU string.h
2010-09-08 11:43 ` Greg Ungerer
@ 2010-09-08 12:01 ` Andreas Schwab
2010-09-08 12:22 ` Greg Ungerer
2010-09-09 19:14 ` Geert Uytterhoeven
1 sibling, 1 reply; 14+ messages in thread
From: Andreas Schwab @ 2010-09-08 12:01 UTC (permalink / raw)
To: Greg Ungerer; +Cc: Geert Uytterhoeven, linux-m68k, gerg
Greg Ungerer <gerg@snapgear.com> writes:
> Hmm, good question. Maybe I should generate stand alone patches
> without gits rename detection turned on?
How did you manage to create the patch? When I try I'm unable to get
this kind of patch even with rename/copy detection (I have set
diff.renamelimit=0 and diff.renames=copies).
Andreas.
--
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5
"And now for something completely different."
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [PATCH] m68k/m68knommu: merge MMU and non-MMU string.h
2010-09-08 12:01 ` Andreas Schwab
@ 2010-09-08 12:22 ` Greg Ungerer
2010-09-08 12:41 ` Andreas Schwab
0 siblings, 1 reply; 14+ messages in thread
From: Greg Ungerer @ 2010-09-08 12:22 UTC (permalink / raw)
To: Andreas Schwab; +Cc: Geert Uytterhoeven, linux-m68k, gerg
Hi Andreas,
On 08/09/10 22:01, Andreas Schwab wrote:
> Greg Ungerer<gerg@snapgear.com> writes:
>
>> Hmm, good question. Maybe I should generate stand alone patches
>> without gits rename detection turned on?
>
> How did you manage to create the patch? When I try I'm unable to get
> this kind of patch even with rename/copy detection (I have set
> diff.renamelimit=0 and diff.renames=copies).
I used:
git format-patch -M -B <COMMIT-ID>
Regards
Greg
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [PATCH] m68k/m68knommu: merge MMU and non-MMU string.h
2010-09-08 12:22 ` Greg Ungerer
@ 2010-09-08 12:41 ` Andreas Schwab
2010-09-08 12:52 ` Geert Uytterhoeven
0 siblings, 1 reply; 14+ messages in thread
From: Andreas Schwab @ 2010-09-08 12:41 UTC (permalink / raw)
To: Greg Ungerer; +Cc: Geert Uytterhoeven, linux-m68k, gerg
Greg Ungerer <gerg@snapgear.com> writes:
> I used:
>
> git format-patch -M -B <COMMIT-ID>
Ok, -B did it. Perhaps worth reporting as a git bug that git am/apply
cannot cope with this.
Andreas.
--
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5
"And now for something completely different."
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [PATCH] m68k/m68knommu: merge MMU and non-MMU string.h
2010-09-08 12:41 ` Andreas Schwab
@ 2010-09-08 12:52 ` Geert Uytterhoeven
0 siblings, 0 replies; 14+ messages in thread
From: Geert Uytterhoeven @ 2010-09-08 12:52 UTC (permalink / raw)
To: Andreas Schwab; +Cc: Greg Ungerer, linux-m68k, gerg
On Wed, Sep 8, 2010 at 14:41, Andreas Schwab <schwab@linux-m68k.org> wrote:
> Greg Ungerer <gerg@snapgear.com> writes:
>
>> I used:
>>
>> git format-patch -M -B <COMMIT-ID>
>
> Ok, -B did it. Perhaps worth reporting as a git bug that git am/apply
> cannot cope with this.
Will do
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [PATCH] m68k/m68knommu: merge MMU and non-MMU string.h
2010-09-08 11:43 ` Greg Ungerer
2010-09-08 12:01 ` Andreas Schwab
@ 2010-09-09 19:14 ` Geert Uytterhoeven
2010-09-10 4:36 ` Greg Ungerer
1 sibling, 1 reply; 14+ messages in thread
From: Geert Uytterhoeven @ 2010-09-09 19:14 UTC (permalink / raw)
To: Greg Ungerer; +Cc: linux-m68k, gerg
On Wed, Sep 8, 2010 at 13:43, Greg Ungerer <gerg@snapgear.com> wrote:
> On 08/09/10 06:35, Geert Uytterhoeven wrote:
>> Now I see:
>>
>> | arch/m68k/kernel/entry.S: Assembler messages:
>> | arch/m68k/kernel/entry.S:56: Error: can't resolve `0' {*ABS* section} - `THREAD_SIZE' {*UND* section}
>> | arch/m68k/kernel/entry.S:64: Error: can't resolve `0' {*UND* section} - `THREAD_SIZE' {*UND* section}
>> | arch/m68k/kernel/entry.S:119: Error: can't resolve `0' {*UND* section} - `THREAD_SIZE' {*UND* section}
>> | arch/m68k/kernel/entry.S:203: Error: can't resolve `0' {*UND* section} - `THREAD_SIZE' {*UND* section}
>> | arch/m68k/kernel/entry.S:236: Error: can't resolve `0' {*UND* section} - `THREAD_SIZE' {*UND* section}
>> | arch/m68k/kernel/entry.S:257: Error: can't resolve `0' {*UND* section} - `THREAD_SIZE' {*UND* section}
>>
>> this is expanded from `GET_CURRENT'.
>
> Just a thought, is it enough to include thread_info.h inside entry_mm.h?
No, because <asm/thread_info.h> is no longer ASSEMBLY-clean, as it includes
<asm/current.h>, which is C-only.
The #include <asm/current.h> in there used to be protected by #ifndef ASSEMBLY.
If I move that include up just above the definition of struct thread_info,
<asm/thread_info.h> is ASSEMBLY-clean again.
However, just including <asm/thread_info.h> from <asm/entry_mm.h> causes other
problems for the C part, as <asm/thread_info.h> needs the definition of struct
restart_block in <linux/thread_info.h>. And <linux/thread_info.h> is definitely
not ASSEMBLY-clean.
So I came up with the patch (white-space damaged due to the GMail web interface)
below. Note that this changes the behavior for m68knommu, which didn't include
<asm/current.h> from <asm/thread_info.h> before. I hope it doesn't hurt...
diff --git a/arch/m68k/include/asm/entry_mm.h b/arch/m68k/include/asm/entry_mm.h
index 6f70823..73b8c8f 100644
--- a/arch/m68k/include/asm/entry_mm.h
+++ b/arch/m68k/include/asm/entry_mm.h
@@ -3,6 +3,9 @@
#include <asm/setup.h>
#include <asm/page.h>
+#ifdef __ASSEMBLY__
+#include <asm/thread_info.h>
+#endif
/*
* Stack layout in 'ret_from_exception':
diff --git a/arch/m68k/include/asm/thread_info.h
b/arch/m68k/include/asm/thread_info.h
index f28775e..aec5eff 100644
--- a/arch/m68k/include/asm/thread_info.h
+++ b/arch/m68k/include/asm/thread_info.h
@@ -22,6 +22,8 @@
#ifndef __ASSEMBLY__
+#include <asm/current.h>
+
struct thread_info {
struct task_struct *task; /* main task structure */
unsigned long flags;
@@ -49,8 +51,6 @@ struct thread_info {
#ifdef CONFIG_MMU
-#include <asm/current.h>
-
#ifdef ASM_OFFSETS_C
#define task_thread_info(tsk) ((struct thread_info *) NULL)
#else
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply related [flat|nested] 14+ messages in thread
* Re: [PATCH] m68k/m68knommu: merge MMU and non-MMU string.h
2010-09-09 19:14 ` Geert Uytterhoeven
@ 2010-09-10 4:36 ` Greg Ungerer
2010-09-10 8:59 ` Geert Uytterhoeven
2010-09-10 9:00 ` Geert Uytterhoeven
0 siblings, 2 replies; 14+ messages in thread
From: Greg Ungerer @ 2010-09-10 4:36 UTC (permalink / raw)
To: Geert Uytterhoeven; +Cc: linux-m68k, gerg
Hi Geert,
Geert Uytterhoeven wrote:
> On Wed, Sep 8, 2010 at 13:43, Greg Ungerer <gerg@snapgear.com> wrote:
>> On 08/09/10 06:35, Geert Uytterhoeven wrote:
>>> Now I see:
>>>
>>> | arch/m68k/kernel/entry.S: Assembler messages:
>>> | arch/m68k/kernel/entry.S:56: Error: can't resolve `0' {*ABS* section} - `THREAD_SIZE' {*UND* section}
>>> | arch/m68k/kernel/entry.S:64: Error: can't resolve `0' {*UND* section} - `THREAD_SIZE' {*UND* section}
>>> | arch/m68k/kernel/entry.S:119: Error: can't resolve `0' {*UND* section} - `THREAD_SIZE' {*UND* section}
>>> | arch/m68k/kernel/entry.S:203: Error: can't resolve `0' {*UND* section} - `THREAD_SIZE' {*UND* section}
>>> | arch/m68k/kernel/entry.S:236: Error: can't resolve `0' {*UND* section} - `THREAD_SIZE' {*UND* section}
>>> | arch/m68k/kernel/entry.S:257: Error: can't resolve `0' {*UND* section} - `THREAD_SIZE' {*UND* section}
>>>
>>> this is expanded from `GET_CURRENT'.
>> Just a thought, is it enough to include thread_info.h inside entry_mm.h?
>
> No, because <asm/thread_info.h> is no longer ASSEMBLY-clean, as it includes
> <asm/current.h>, which is C-only.
> The #include <asm/current.h> in there used to be protected by #ifndef ASSEMBLY.
> If I move that include up just above the definition of struct thread_info,
> <asm/thread_info.h> is ASSEMBLY-clean again.
>
> However, just including <asm/thread_info.h> from <asm/entry_mm.h> causes other
> problems for the C part, as <asm/thread_info.h> needs the definition of struct
> restart_block in <linux/thread_info.h>. And <linux/thread_info.h> is definitely
> not ASSEMBLY-clean.
>
> So I came up with the patch (white-space damaged due to the GMail web interface)
> below. Note that this changes the behavior for m68knommu, which didn't include
> <asm/current.h> from <asm/thread_info.h> before. I hope it doesn't hurt...
Unfortunately that breaks the m68knommu build:
/home/gerg/new-wave.2635/linux-2.6.x.git/arch/m68k/include/asm/current.h:
In function ‘get_current’:
/home/gerg/new-wave.2635/linux-2.6.x.git/arch/m68k/include/asm/current.h:21:
error: implicit declaration of function ‘current_thread_info’
...
If we just wrap the include of asm/current.h with its own "#ifndef
__ASSEMBLY__", instead of moving it from above struct thread_info,
is that better for you?
Regards
Greg
> diff --git a/arch/m68k/include/asm/entry_mm.h b/arch/m68k/include/asm/entry_mm.h
> index 6f70823..73b8c8f 100644
> --- a/arch/m68k/include/asm/entry_mm.h
> +++ b/arch/m68k/include/asm/entry_mm.h
> @@ -3,6 +3,9 @@
>
> #include <asm/setup.h>
> #include <asm/page.h>
> +#ifdef __ASSEMBLY__
> +#include <asm/thread_info.h>
> +#endif
>
> /*
> * Stack layout in 'ret_from_exception':
> diff --git a/arch/m68k/include/asm/thread_info.h
> b/arch/m68k/include/asm/thread_info.h
> index f28775e..aec5eff 100644
> --- a/arch/m68k/include/asm/thread_info.h
> +++ b/arch/m68k/include/asm/thread_info.h
> @@ -22,6 +22,8 @@
>
> #ifndef __ASSEMBLY__
>
> +#include <asm/current.h>
> +
> struct thread_info {
> struct task_struct *task; /* main task structure */
> unsigned long flags;
> @@ -49,8 +51,6 @@ struct thread_info {
>
> #ifdef CONFIG_MMU
>
> -#include <asm/current.h>
> -
> #ifdef ASM_OFFSETS_C
> #define task_thread_info(tsk) ((struct thread_info *) NULL)
> #else
>
> Gr{oetje,eeting}s,
>
> Geert
>
> --
> Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
>
> In personal conversations with technical people, I call myself a hacker. But
> when I'm talking to journalists I just say "programmer" or something like that.
> -- Linus Torvalds
>
--
------------------------------------------------------------------------
Greg Ungerer -- Principal Engineer EMAIL: gerg@snapgear.com
SnapGear Group, McAfee PHONE: +61 7 3435 2888
8 Gardner Close FAX: +61 7 3217 5323
Milton, QLD, 4064, Australia WEB: http://www.SnapGear.com
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [PATCH] m68k/m68knommu: merge MMU and non-MMU string.h
2010-09-10 4:36 ` Greg Ungerer
@ 2010-09-10 8:59 ` Geert Uytterhoeven
2010-09-10 9:00 ` Geert Uytterhoeven
1 sibling, 0 replies; 14+ messages in thread
From: Geert Uytterhoeven @ 2010-09-10 8:59 UTC (permalink / raw)
To: Greg Ungerer; +Cc: linux-m68k, gerg
On Fri, Sep 10, 2010 at 06:36, Greg Ungerer <gerg@snapgear.com> wrote:
> Geert Uytterhoeven wrote:
>>
>> On Wed, Sep 8, 2010 at 13:43, Greg Ungerer <gerg@snapgear.com> wrote:
>>>
>>> On 08/09/10 06:35, Geert Uytterhoeven wrote:
>>>>
>>>> Now I see:
>>>>
>>>> | arch/m68k/kernel/entry.S: Assembler messages:
>>>> | arch/m68k/kernel/entry.S:56: Error: can't resolve `0' {*ABS* section}
>>>> - `THREAD_SIZE' {*UND* section}
>>>> | arch/m68k/kernel/entry.S:64: Error: can't resolve `0' {*UND* section}
>>>> - `THREAD_SIZE' {*UND* section}
>>>> | arch/m68k/kernel/entry.S:119: Error: can't resolve `0' {*UND* section}
>>>> - `THREAD_SIZE' {*UND* section}
>>>> | arch/m68k/kernel/entry.S:203: Error: can't resolve `0' {*UND* section}
>>>> - `THREAD_SIZE' {*UND* section}
>>>> | arch/m68k/kernel/entry.S:236: Error: can't resolve `0' {*UND* section}
>>>> - `THREAD_SIZE' {*UND* section}
>>>> | arch/m68k/kernel/entry.S:257: Error: can't resolve `0' {*UND* section}
>>>> - `THREAD_SIZE' {*UND* section}
>>>>
>>>> this is expanded from `GET_CURRENT'.
>>>
>>> Just a thought, is it enough to include thread_info.h inside entry_mm.h?
>>
>> No, because <asm/thread_info.h> is no longer ASSEMBLY-clean, as it
>> includes
>> <asm/current.h>, which is C-only.
>> The #include <asm/current.h> in there used to be protected by #ifndef
>> ASSEMBLY.
>> If I move that include up just above the definition of struct thread_info,
>> <asm/thread_info.h> is ASSEMBLY-clean again.
>>
>> However, just including <asm/thread_info.h> from <asm/entry_mm.h> causes
>> other
>> problems for the C part, as <asm/thread_info.h> needs the definition of
>> struct
>> restart_block in <linux/thread_info.h>. And <linux/thread_info.h> is
>> definitely
>> not ASSEMBLY-clean.
>>
>> So I came up with the patch (white-space damaged due to the GMail web
>> interface)
>> below. Note that this changes the behavior for m68knommu, which didn't
>> include
>> <asm/current.h> from <asm/thread_info.h> before. I hope it doesn't hurt...
>
> Unfortunately that breaks the m68knommu build:
>
> /home/gerg/new-wave.2635/linux-2.6.x.git/arch/m68k/include/asm/current.h: In
> function ‘get_current’:
> /home/gerg/new-wave.2635/linux-2.6.x.git/arch/m68k/include/asm/current.h:21:
> error: implicit declaration of function ‘current_thread_info’
> ...
>
> If we just wrap the include of asm/current.h with its own "#ifndef
> __ASSEMBLY__", instead of moving it from above struct thread_info,
> is that better for you?
>
> Regards
> Greg
>
>
>
>> diff --git a/arch/m68k/include/asm/entry_mm.h
>> b/arch/m68k/include/asm/entry_mm.h
>> index 6f70823..73b8c8f 100644
>> --- a/arch/m68k/include/asm/entry_mm.h
>> +++ b/arch/m68k/include/asm/entry_mm.h
>> @@ -3,6 +3,9 @@
>>
>> #include <asm/setup.h>
>> #include <asm/page.h>
>> +#ifdef __ASSEMBLY__
>> +#include <asm/thread_info.h>
>> +#endif
>>
>> /*
>> * Stack layout in 'ret_from_exception':
>> diff --git a/arch/m68k/include/asm/thread_info.h
>> b/arch/m68k/include/asm/thread_info.h
>> index f28775e..aec5eff 100644
>> --- a/arch/m68k/include/asm/thread_info.h
>> +++ b/arch/m68k/include/asm/thread_info.h
>> @@ -22,6 +22,8 @@
>>
>> #ifndef __ASSEMBLY__
>>
>> +#include <asm/current.h>
>> +
>> struct thread_info {
>> struct task_struct *task; /* main task structure */
>> unsigned long flags;
>> @@ -49,8 +51,6 @@ struct thread_info {
>>
>> #ifdef CONFIG_MMU
>>
>> -#include <asm/current.h>
>> -
>> #ifdef ASM_OFFSETS_C
>> #define task_thread_info(tsk) ((struct thread_info *) NULL)
>> #else
>>
>> Gr{oetje,eeting}s,
>>
>> Geert
>>
>> --
>> Geert Uytterhoeven -- There's lots of Linux beyond ia32 --
>> geert@linux-m68k.org
>>
>> In personal conversations with technical people, I call myself a hacker.
>> But
>> when I'm talking to journalists I just say "programmer" or something like
>> that.
>> -- Linus Torvalds
>>
>
>
> --
> ------------------------------------------------------------------------
> Greg Ungerer -- Principal Engineer EMAIL: gerg@snapgear.com
> SnapGear Group, McAfee PHONE: +61 7 3435 2888
> 8 Gardner Close FAX: +61 7 3217 5323
> Milton, QLD, 4064, Australia WEB: http://www.SnapGear.com
> --
> To unsubscribe from this list: send the line "unsubscribe linux-m68k" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
--
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [PATCH] m68k/m68knommu: merge MMU and non-MMU string.h
2010-09-10 4:36 ` Greg Ungerer
2010-09-10 8:59 ` Geert Uytterhoeven
@ 2010-09-10 9:00 ` Geert Uytterhoeven
2010-09-13 3:22 ` Greg Ungerer
1 sibling, 1 reply; 14+ messages in thread
From: Geert Uytterhoeven @ 2010-09-10 9:00 UTC (permalink / raw)
To: Greg Ungerer; +Cc: linux-m68k, gerg
Hi Greg,
On Fri, Sep 10, 2010 at 06:36, Greg Ungerer <gerg@snapgear.com> wrote:
> Geert Uytterhoeven wrote:
>> On Wed, Sep 8, 2010 at 13:43, Greg Ungerer <gerg@snapgear.com> wrote:
>>> On 08/09/10 06:35, Geert Uytterhoeven wrote:
>>>>
>>>> Now I see:
>>>>
>>>> | arch/m68k/kernel/entry.S: Assembler messages:
>>>> | arch/m68k/kernel/entry.S:56: Error: can't resolve `0' {*ABS* section}
>>>> - `THREAD_SIZE' {*UND* section}
>>>> | arch/m68k/kernel/entry.S:64: Error: can't resolve `0' {*UND* section}
>>>> - `THREAD_SIZE' {*UND* section}
>>>> | arch/m68k/kernel/entry.S:119: Error: can't resolve `0' {*UND* section}
>>>> - `THREAD_SIZE' {*UND* section}
>>>> | arch/m68k/kernel/entry.S:203: Error: can't resolve `0' {*UND* section}
>>>> - `THREAD_SIZE' {*UND* section}
>>>> | arch/m68k/kernel/entry.S:236: Error: can't resolve `0' {*UND* section}
>>>> - `THREAD_SIZE' {*UND* section}
>>>> | arch/m68k/kernel/entry.S:257: Error: can't resolve `0' {*UND* section}
>>>> - `THREAD_SIZE' {*UND* section}
>>>>
>>>> this is expanded from `GET_CURRENT'.
>>>
>>> Just a thought, is it enough to include thread_info.h inside entry_mm.h?
>>
>> No, because <asm/thread_info.h> is no longer ASSEMBLY-clean, as it
>> includes
>> <asm/current.h>, which is C-only.
>> The #include <asm/current.h> in there used to be protected by #ifndef
>> ASSEMBLY.
>> If I move that include up just above the definition of struct thread_info,
>> <asm/thread_info.h> is ASSEMBLY-clean again.
>>
>> However, just including <asm/thread_info.h> from <asm/entry_mm.h> causes
>> other
>> problems for the C part, as <asm/thread_info.h> needs the definition of
>> struct
>> restart_block in <linux/thread_info.h>. And <linux/thread_info.h> is
>> definitely
>> not ASSEMBLY-clean.
>>
>> So I came up with the patch (white-space damaged due to the GMail web
>> interface)
>> below. Note that this changes the behavior for m68knommu, which didn't
>> include
>> <asm/current.h> from <asm/thread_info.h> before. I hope it doesn't hurt...
>
> Unfortunately that breaks the m68knommu build:
>
> /home/gerg/new-wave.2635/linux-2.6.x.git/arch/m68k/include/asm/current.h: In
> function ‘get_current’:
> /home/gerg/new-wave.2635/linux-2.6.x.git/arch/m68k/include/asm/current.h:21:
> error: implicit declaration of function ‘current_thread_info’
> ...
>
> If we just wrap the include of asm/current.h with its own "#ifndef
> __ASSEMBLY__", instead of moving it from above struct thread_info,
> is that better for you?
Builds fine, too.
>> diff --git a/arch/m68k/include/asm/entry_mm.h
>> b/arch/m68k/include/asm/entry_mm.h
>> index 6f70823..73b8c8f 100644
>> --- a/arch/m68k/include/asm/entry_mm.h
>> +++ b/arch/m68k/include/asm/entry_mm.h
>> @@ -3,6 +3,9 @@
>>
>> #include <asm/setup.h>
>> #include <asm/page.h>
>> +#ifdef __ASSEMBLY__
>> +#include <asm/thread_info.h>
>> +#endif
>>
>> /*
>> * Stack layout in 'ret_from_exception':
>> diff --git a/arch/m68k/include/asm/thread_info.h
>> b/arch/m68k/include/asm/thread_info.h
>> index f28775e..aec5eff 100644
>> --- a/arch/m68k/include/asm/thread_info.h
>> +++ b/arch/m68k/include/asm/thread_info.h
>> @@ -22,6 +22,8 @@
>>
>> #ifndef __ASSEMBLY__
>>
>> +#include <asm/current.h>
>> +
>> struct thread_info {
>> struct task_struct *task; /* main task structure */
>> unsigned long flags;
>> @@ -49,8 +51,6 @@ struct thread_info {
>>
>> #ifdef CONFIG_MMU
>>
>> -#include <asm/current.h>
>> -
>> #ifdef ASM_OFFSETS_C
>> #define task_thread_info(tsk) ((struct thread_info *) NULL)
>> #else
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [PATCH] m68k/m68knommu: merge MMU and non-MMU string.h
2010-09-10 9:00 ` Geert Uytterhoeven
@ 2010-09-13 3:22 ` Greg Ungerer
0 siblings, 0 replies; 14+ messages in thread
From: Greg Ungerer @ 2010-09-13 3:22 UTC (permalink / raw)
To: Geert Uytterhoeven; +Cc: linux-m68k, gerg
Hi Geert,
Geert Uytterhoeven wrote:
> On Fri, Sep 10, 2010 at 06:36, Greg Ungerer <gerg@snapgear.com> wrote:
>> Geert Uytterhoeven wrote:
>>> On Wed, Sep 8, 2010 at 13:43, Greg Ungerer <gerg@snapgear.com> wrote:
>>>> On 08/09/10 06:35, Geert Uytterhoeven wrote:
>>>>> Now I see:
>>>>>
>>>>> | arch/m68k/kernel/entry.S: Assembler messages:
>>>>> | arch/m68k/kernel/entry.S:56: Error: can't resolve `0' {*ABS* section}
>>>>> - `THREAD_SIZE' {*UND* section}
>>>>> | arch/m68k/kernel/entry.S:64: Error: can't resolve `0' {*UND* section}
>>>>> - `THREAD_SIZE' {*UND* section}
>>>>> | arch/m68k/kernel/entry.S:119: Error: can't resolve `0' {*UND* section}
>>>>> - `THREAD_SIZE' {*UND* section}
>>>>> | arch/m68k/kernel/entry.S:203: Error: can't resolve `0' {*UND* section}
>>>>> - `THREAD_SIZE' {*UND* section}
>>>>> | arch/m68k/kernel/entry.S:236: Error: can't resolve `0' {*UND* section}
>>>>> - `THREAD_SIZE' {*UND* section}
>>>>> | arch/m68k/kernel/entry.S:257: Error: can't resolve `0' {*UND* section}
>>>>> - `THREAD_SIZE' {*UND* section}
>>>>>
>>>>> this is expanded from `GET_CURRENT'.
>>>> Just a thought, is it enough to include thread_info.h inside entry_mm.h?
>>> No, because <asm/thread_info.h> is no longer ASSEMBLY-clean, as it
>>> includes
>>> <asm/current.h>, which is C-only.
>>> The #include <asm/current.h> in there used to be protected by #ifndef
>>> ASSEMBLY.
>>> If I move that include up just above the definition of struct thread_info,
>>> <asm/thread_info.h> is ASSEMBLY-clean again.
>>>
>>> However, just including <asm/thread_info.h> from <asm/entry_mm.h> causes
>>> other
>>> problems for the C part, as <asm/thread_info.h> needs the definition of
>>> struct
>>> restart_block in <linux/thread_info.h>. And <linux/thread_info.h> is
>>> definitely
>>> not ASSEMBLY-clean.
>>>
>>> So I came up with the patch (white-space damaged due to the GMail web
>>> interface)
>>> below. Note that this changes the behavior for m68knommu, which didn't
>>> include
>>> <asm/current.h> from <asm/thread_info.h> before. I hope it doesn't hurt...
>> Unfortunately that breaks the m68knommu build:
>>
>> /home/gerg/new-wave.2635/linux-2.6.x.git/arch/m68k/include/asm/current.h: In
>> function ‘get_current’:
>> /home/gerg/new-wave.2635/linux-2.6.x.git/arch/m68k/include/asm/current.h:21:
>> error: implicit declaration of function ‘current_thread_info’
>> ...
>>
>> If we just wrap the include of asm/current.h with its own "#ifndef
>> __ASSEMBLY__", instead of moving it from above struct thread_info,
>> is that better for you?
>
> Builds fine, too.
Ok, thanks. I'll generate a new patch based on this.
Regards
Greg
>>> diff --git a/arch/m68k/include/asm/entry_mm.h
>>> b/arch/m68k/include/asm/entry_mm.h
>>> index 6f70823..73b8c8f 100644
>>> --- a/arch/m68k/include/asm/entry_mm.h
>>> +++ b/arch/m68k/include/asm/entry_mm.h
>>> @@ -3,6 +3,9 @@
>>>
>>> #include <asm/setup.h>
>>> #include <asm/page.h>
>>> +#ifdef __ASSEMBLY__
>>> +#include <asm/thread_info.h>
>>> +#endif
>>>
>>> /*
>>> * Stack layout in 'ret_from_exception':
>>> diff --git a/arch/m68k/include/asm/thread_info.h
>>> b/arch/m68k/include/asm/thread_info.h
>>> index f28775e..aec5eff 100644
>>> --- a/arch/m68k/include/asm/thread_info.h
>>> +++ b/arch/m68k/include/asm/thread_info.h
>>> @@ -22,6 +22,8 @@
>>>
>>> #ifndef __ASSEMBLY__
>>>
>>> +#include <asm/current.h>
>>> +
>>> struct thread_info {
>>> struct task_struct *task; /* main task structure */
>>> unsigned long flags;
>>> @@ -49,8 +51,6 @@ struct thread_info {
>>>
>>> #ifdef CONFIG_MMU
>>>
>>> -#include <asm/current.h>
>>> -
>>> #ifdef ASM_OFFSETS_C
>>> #define task_thread_info(tsk) ((struct thread_info *) NULL)
>>> #else
>
> Gr{oetje,eeting}s,
>
> Geert
>
> --
> Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
>
> In personal conversations with technical people, I call myself a hacker. But
> when I'm talking to journalists I just say "programmer" or something like that.
> -- Linus Torvalds
>
--
------------------------------------------------------------------------
Greg Ungerer -- Principal Engineer EMAIL: gerg@snapgear.com
SnapGear Group, McAfee PHONE: +61 7 3435 2888
8 Gardner Close FAX: +61 7 3217 5323
Milton, QLD, 4064, Australia WEB: http://www.SnapGear.com
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [PATCH] m68k/m68knommu: merge MMU and non-MMU string.h
2010-09-07 4:52 [PATCH] m68k/m68knommu: merge MMU and non-MMU string.h Greg Ungerer
2010-09-07 20:35 ` Geert Uytterhoeven
@ 2010-09-13 18:22 ` Geert Uytterhoeven
1 sibling, 0 replies; 14+ messages in thread
From: Geert Uytterhoeven @ 2010-09-13 18:22 UTC (permalink / raw)
To: Greg Ungerer; +Cc: linux-m68k, gerg
On Tue, Sep 7, 2010 at 06:52, Greg Ungerer <gerg@snapgear.com> wrote:
> m68k/m68knommu: merge MMU and non-MMU string.h
I've applied the whole series:
m68k: move definition of THREAD_SIZE into thread_info_mm.h
m68k/m68knommu: merge MMU and non-MMU string.h
m68k/m68knommu: merge machdep.h files into a single file
m68k/m68knommu: clean up page.h
m68k/m68knommu: merge MMU and non-MMU atomic.h
m68k/m68knommu: merge MMU and non-MMU thread_info.h
m68k/m68knommu: merge the MMU and non-MMU traps.h
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply [flat|nested] 14+ messages in thread
end of thread, other threads:[~2010-09-13 18:22 UTC | newest]
Thread overview: 14+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2010-09-07 4:52 [PATCH] m68k/m68knommu: merge MMU and non-MMU string.h Greg Ungerer
2010-09-07 20:35 ` Geert Uytterhoeven
2010-09-07 20:45 ` Geert Uytterhoeven
2010-09-08 11:43 ` Greg Ungerer
2010-09-08 12:01 ` Andreas Schwab
2010-09-08 12:22 ` Greg Ungerer
2010-09-08 12:41 ` Andreas Schwab
2010-09-08 12:52 ` Geert Uytterhoeven
2010-09-09 19:14 ` Geert Uytterhoeven
2010-09-10 4:36 ` Greg Ungerer
2010-09-10 8:59 ` Geert Uytterhoeven
2010-09-10 9:00 ` Geert Uytterhoeven
2010-09-13 3:22 ` Greg Ungerer
2010-09-13 18:22 ` Geert Uytterhoeven
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.