All of lore.kernel.org
 help / color / mirror / Atom feed
* [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.