Re: [PATCH] linkage.h: fix build breakage due to symbol prefix handling

2013-05-07 Thread Stephen Rothwell
Hi Rusty,

On Mon, 06 May 2013 14:59:05 +0930 Rusty Russell  wrote:
>
> Stephen Rothwell  writes:
> > Version from today's merge fix.  Rusty, you should show this to Linus
> > when you ask him to merge your modules tree (assuming it looks right :-)).
> >
> > From: Stephen Rothwell 
> > Date: Thu, 14 Mar 2013 17:14:41 +1100
> > Subject: [PATCH] cond_syscall and SYSCALL_ALIAS merge fixup
> >
> > Signed-off-by: Stephen Rothwell 
> 
> I ended up with something similar, except I didn't remove
> linux/stringify.h from the includes.

Well, the stringify include was only added in Al's patch during this
merge window, so it should be perfectly safe to remove again (now that
all the "stringify" calls have been removed again).

-- 
Cheers,
Stephen Rothwells...@canb.auug.org.au


pgpwiiuUF0UgJ.pgp
Description: PGP signature


Re: [PATCH] linkage.h: fix build breakage due to symbol prefix handling

2013-05-06 Thread Rusty Russell
Stephen Rothwell  writes:
> Version from today's merge fix.  Rusty, you should show this to Linus
> when you ask him to merge your modules tree (assuming it looks right :-)).
>
> From: Stephen Rothwell 
> Date: Thu, 14 Mar 2013 17:14:41 +1100
> Subject: [PATCH] cond_syscall and SYSCALL_ALIAS merge fixup
>
> Signed-off-by: Stephen Rothwell 

I ended up with something similar, except I didn't remove
linux/stringify.h from the includes.

Thanks!
Rusty.

> ---
>  include/linux/linkage.h |   17 ++---
>  1 file changed, 6 insertions(+), 11 deletions(-)
>
> diff --git a/include/linux/linkage.h b/include/linux/linkage.h
> index de09dec..bedcddf 100644
> --- a/include/linux/linkage.h
> +++ b/include/linux/linkage.h
> @@ -2,7 +2,7 @@
>  #define _LINUX_LINKAGE_H
>  
>  #include 
> -#include 
> +#include 
>  #include 
>  
>  #ifdef __cplusplus
> @@ -15,21 +15,16 @@
>  #define asmlinkage CPP_ASMLINKAGE
>  #endif
>  
> -#ifdef CONFIG_SYMBOL_PREFIX
> -#define __SYMBOL_NAME(x) CONFIG_SYMBOL_PREFIX __stringify(x)
> -#else
> -#define __SYMBOL_NAME(x) __stringify(x)
> -#endif
> -
>  #ifndef cond_syscall
> -#define cond_syscall(x) asm(".weak\t" __SYMBOL_NAME(x) \
> - "\n\t.set\t" __SYMBOL_NAME(x) "," __SYMBOL_NAME(sys_ni_syscall));
> +#define cond_syscall(x) asm(".weak\t" VMLINUX_SYMBOL_STR(x) "\n\t"   \
> + ".set\t" VMLINUX_SYMBOL_STR(x) ","  \
> + VMLINUX_SYMBOL_STR(sys_ni_syscall))
>  #endif
>  
>  #ifndef SYSCALL_ALIAS
>  #define SYSCALL_ALIAS(alias, name)   \
> - asm ("\t.globl " __SYMBOL_NAME(alias)   \
> - "\n\t.set\t" __SYMBOL_NAME(alias) "," __SYMBOL_NAME(name))
> + asm ("\t.globl " VMLINUX_SYMBOL_STR(alias)  \
> + "\n\t.set\t" VMLINUX_SYMBOL_STR(alias) "," VMLINUX_SYMBOL_STR(name))
>  #endif
>  
>  #define __page_aligned_data  __section(.data..page_aligned) 
> __aligned(PAGE_SIZE)
>
> -- 
> Cheers,
> Stephen Rothwells...@canb.auug.org.au
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


Re: [PATCH] linkage.h: fix build breakage due to symbol prefix handling

2013-05-01 Thread Stephen Rothwell
Hi Rusty,

On Thu, 2 May 2013 13:37:37 +1000 Stephen Rothwell  
wrote:
>
> This is the merge fix patch I have been carrying in linux-next since
> March 14: (this probably does not quite apply any more but, hey ...)
> 
> From: Stephen Rothwell 
> Date: Thu, 14 Mar 2013 17:14:41 +1100
> Subject: [PATCH] cond_syscall and SYSCALL_ALIAS merge fixup
> 
> Signed-off-by: Stephen Rothwell 
> ---
>  include/linux/linkage.h | 20 ++--
>  1 file changed, 6 insertions(+), 14 deletions(-)
> 
> diff --git a/include/linux/linkage.h b/include/linux/linkage.h
> index 829d66c..bedcddf 100644
> --- a/include/linux/linkage.h
> +++ b/include/linux/linkage.h
> @@ -2,7 +2,7 @@
>  #define _LINUX_LINKAGE_H
>  
>  #include 
> -#include 
> +#include 
>  #include 
>  
>  #ifdef __cplusplus
> @@ -15,24 +15,16 @@
>  #define asmlinkage CPP_ASMLINKAGE
>  #endif
>  
> -#ifndef SYMBOL_NAME
> -#ifdef CONFIG_SYMBOL_PREFIX
> -#define SYMBOL_NAME(x) CONFIG_SYMBOL_PREFIX ## x
> -#else
> -#define SYMBOL_NAME(x) x
> -#endif
> -#endif
> -#define __SYMBOL_NAME(x) __stringify(SYMBOL_NAME(x))
> -
>  #ifndef cond_syscall
> -#define cond_syscall(x) asm(".weak\t" __SYMBOL_NAME(x) \
> - "\n\t.set\t" __SYMBOL_NAME(x) "," __SYMBOL_NAME(sys_ni_syscall));
> +#define cond_syscall(x) asm(".weak\t" VMLINUX_SYMBOL_STR(x) "\n\t"   \
> + ".set\t" VMLINUX_SYMBOL_STR(x) ","  \
> + VMLINUX_SYMBOL_STR(sys_ni_syscall))
>  #endif
>  
>  #ifndef SYSCALL_ALIAS
>  #define SYSCALL_ALIAS(alias, name)   \
> - asm ("\t.globl " __SYMBOL_NAME(alias)   \
> - "\n\t.set\t" __SYMBOL_NAME(alias) "," __SYMBOL_NAME(name))
> + asm ("\t.globl " VMLINUX_SYMBOL_STR(alias)  \
> + "\n\t.set\t" VMLINUX_SYMBOL_STR(alias) "," VMLINUX_SYMBOL_STR(name))
>  #endif
>  
>  #define __page_aligned_data  __section(.data..page_aligned) 
> __aligned(PAGE_SIZE)
> -- 
> 1.8.1

Version from today's merge fix.  Rusty, you should show this to Linus
when you ask him to merge your modules tree (assuming it looks right :-)).

From: Stephen Rothwell 
Date: Thu, 14 Mar 2013 17:14:41 +1100
Subject: [PATCH] cond_syscall and SYSCALL_ALIAS merge fixup

Signed-off-by: Stephen Rothwell 
---
 include/linux/linkage.h |   17 ++---
 1 file changed, 6 insertions(+), 11 deletions(-)

diff --git a/include/linux/linkage.h b/include/linux/linkage.h
index de09dec..bedcddf 100644
--- a/include/linux/linkage.h
+++ b/include/linux/linkage.h
@@ -2,7 +2,7 @@
 #define _LINUX_LINKAGE_H
 
 #include 
-#include 
+#include 
 #include 
 
 #ifdef __cplusplus
@@ -15,21 +15,16 @@
 #define asmlinkage CPP_ASMLINKAGE
 #endif
 
-#ifdef CONFIG_SYMBOL_PREFIX
-#define __SYMBOL_NAME(x) CONFIG_SYMBOL_PREFIX __stringify(x)
-#else
-#define __SYMBOL_NAME(x) __stringify(x)
-#endif
-
 #ifndef cond_syscall
-#define cond_syscall(x) asm(".weak\t" __SYMBOL_NAME(x) \
-   "\n\t.set\t" __SYMBOL_NAME(x) "," __SYMBOL_NAME(sys_ni_syscall));
+#define cond_syscall(x) asm(".weak\t" VMLINUX_SYMBOL_STR(x) "\n\t" \
+   ".set\t" VMLINUX_SYMBOL_STR(x) ","  \
+   VMLINUX_SYMBOL_STR(sys_ni_syscall))
 #endif
 
 #ifndef SYSCALL_ALIAS
 #define SYSCALL_ALIAS(alias, name) \
-   asm ("\t.globl " __SYMBOL_NAME(alias)   \
-   "\n\t.set\t" __SYMBOL_NAME(alias) "," __SYMBOL_NAME(name))
+   asm ("\t.globl " VMLINUX_SYMBOL_STR(alias)  \
+   "\n\t.set\t" VMLINUX_SYMBOL_STR(alias) "," VMLINUX_SYMBOL_STR(name))
 #endif
 
 #define __page_aligned_data__section(.data..page_aligned) 
__aligned(PAGE_SIZE)

-- 
Cheers,
Stephen Rothwells...@canb.auug.org.au


pgpqMTK92Xb4E.pgp
Description: PGP signature


Re: [PATCH] linkage.h: fix build breakage due to symbol prefix handling

2013-05-01 Thread Al Viro
On Wed, May 01, 2013 at 10:43:35PM +0100, Al Viro wrote:

> Oh, hell...  Guys, my deep apologies - what happened is that this thing
> has been caught in -next, rebase done here (on top of Rusty's commit)
> and *not* pushed to linux-next.

Curiouser and curiouser...  FWIW, what I have is
$ cat .git/refs/heads/linkage-fixed
898429c05290b8c05d035199f65a3bb034b34bb7
$ cat .git/refs/heads/remotes/next
898429c05290b8c05d035199f65a3bb034b34bb7
both being the aforementioned rebase;  I really wonder WTF had I been doing
that could've produced that...  How does git deal with that sort of
ambiguities?
$ git log remotes/next | head -3
commit 898429c05290b8c05d035199f65a3bb034b34bb7
Author: Al Viro 
Date:   Tue Mar 19 14:25:51 2013 -0400
$ git log remotes/next/master | head -3
commit d7c35d45ce991ae01b6008abef120173fc9c3814
Author: Stephen Rothwell 
Date:   Tue Apr 30 16:26:41 2013 +1000
(the latter, of course, coming from remote for linux-next mirror)
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


Re: [PATCH] linkage.h: fix build breakage due to symbol prefix handling

2013-05-01 Thread Stephen Rothwell
Hi all,

On Thu, 02 May 2013 09:58:08 +0930 Rusty Russell  wrote:
>
> James Hogan  writes:
> > Al's commit e1b5bb6d1236d4ad2084c53aa83dde7cdf6f8eea ("consolidate
> > cond_syscall and SYSCALL_ALIAS declarations") broke the build on
> > blackfin and metag due to the following code:
> >
> >   #ifndef SYMBOL_NAME
> >   #ifdef CONFIG_SYMBOL_PREFIX
> >   #define SYMBOL_NAME(x) CONFIG_SYMBOL_PREFIX ## x
> >   #else
> >   #define SYMBOL_NAME(x) x
> >   #endif
> >   #endif
> >   #define __SYMBOL_NAME(x) __stringify(SYMBOL_NAME(x))
> >
> > __stringify literally stringifies CONFIG_SYMBOL_PREFIX ##x, so you get
> > lines like this in kernel/sys_ni.s:
> >
> >   .weak CONFIG_SYMBOL_PREFIXsys_quotactl
> >   .set CONFIG_SYMBOL_PREFIXsys_quotactl,CONFIG_SYMBOL_PREFIXsys_ni_syscall
> >
> > The patches in Rusty's modules-next tree such as "CONFIG_SYMBOL_PREFIX:
> > cleanup." clean up the whole mess around symbol prefixes, so this patch
> > just attempts to fix the build in the mean time. The intermediate
> > definition of SYMBOL_NAME above isn't used and is incorrect when
> > CONFIG_SYMBOL_PREFIX is defined as CONFIG_SYMBOL_PREFIX is a quoted
> > string literal, so define __SYMBOL_NAME directly depending on
> > CONFIG_SYMBOL_PREFIX.
> 
> I just pushed my modules-next tree to Linus, so hopefully the nightmare
> is over soon!

This is the merge fix patch I have been carrying in linux-next since
March 14: (this probably does not quite apply any more but, hey ...)

From: Stephen Rothwell 
Date: Thu, 14 Mar 2013 17:14:41 +1100
Subject: [PATCH] cond_syscall and SYSCALL_ALIAS merge fixup

Signed-off-by: Stephen Rothwell 
---
 include/linux/linkage.h | 20 ++--
 1 file changed, 6 insertions(+), 14 deletions(-)

diff --git a/include/linux/linkage.h b/include/linux/linkage.h
index 829d66c..bedcddf 100644
--- a/include/linux/linkage.h
+++ b/include/linux/linkage.h
@@ -2,7 +2,7 @@
 #define _LINUX_LINKAGE_H
 
 #include 
-#include 
+#include 
 #include 
 
 #ifdef __cplusplus
@@ -15,24 +15,16 @@
 #define asmlinkage CPP_ASMLINKAGE
 #endif
 
-#ifndef SYMBOL_NAME
-#ifdef CONFIG_SYMBOL_PREFIX
-#define SYMBOL_NAME(x) CONFIG_SYMBOL_PREFIX ## x
-#else
-#define SYMBOL_NAME(x) x
-#endif
-#endif
-#define __SYMBOL_NAME(x) __stringify(SYMBOL_NAME(x))
-
 #ifndef cond_syscall
-#define cond_syscall(x) asm(".weak\t" __SYMBOL_NAME(x) \
-   "\n\t.set\t" __SYMBOL_NAME(x) "," __SYMBOL_NAME(sys_ni_syscall));
+#define cond_syscall(x) asm(".weak\t" VMLINUX_SYMBOL_STR(x) "\n\t" \
+   ".set\t" VMLINUX_SYMBOL_STR(x) ","  \
+   VMLINUX_SYMBOL_STR(sys_ni_syscall))
 #endif
 
 #ifndef SYSCALL_ALIAS
 #define SYSCALL_ALIAS(alias, name) \
-   asm ("\t.globl " __SYMBOL_NAME(alias)   \
-   "\n\t.set\t" __SYMBOL_NAME(alias) "," __SYMBOL_NAME(name))
+   asm ("\t.globl " VMLINUX_SYMBOL_STR(alias)  \
+   "\n\t.set\t" VMLINUX_SYMBOL_STR(alias) "," VMLINUX_SYMBOL_STR(name))
 #endif
 
 #define __page_aligned_data__section(.data..page_aligned) 
__aligned(PAGE_SIZE)
-- 
1.8.1

-- 
Cheers,
Stephen Rothwells...@canb.auug.org.au


pgpA1NA_qYpLt.pgp
Description: PGP signature


Re: [PATCH] linkage.h: fix build breakage due to symbol prefix handling

2013-05-01 Thread Rusty Russell
James Hogan  writes:
> Al's commit e1b5bb6d1236d4ad2084c53aa83dde7cdf6f8eea ("consolidate
> cond_syscall and SYSCALL_ALIAS declarations") broke the build on
> blackfin and metag due to the following code:
>
>   #ifndef SYMBOL_NAME
>   #ifdef CONFIG_SYMBOL_PREFIX
>   #define SYMBOL_NAME(x) CONFIG_SYMBOL_PREFIX ## x
>   #else
>   #define SYMBOL_NAME(x) x
>   #endif
>   #endif
>   #define __SYMBOL_NAME(x) __stringify(SYMBOL_NAME(x))
>
> __stringify literally stringifies CONFIG_SYMBOL_PREFIX ##x, so you get
> lines like this in kernel/sys_ni.s:
>
>   .weak CONFIG_SYMBOL_PREFIXsys_quotactl
>   .set CONFIG_SYMBOL_PREFIXsys_quotactl,CONFIG_SYMBOL_PREFIXsys_ni_syscall
>
> The patches in Rusty's modules-next tree such as "CONFIG_SYMBOL_PREFIX:
> cleanup." clean up the whole mess around symbol prefixes, so this patch
> just attempts to fix the build in the mean time. The intermediate
> definition of SYMBOL_NAME above isn't used and is incorrect when
> CONFIG_SYMBOL_PREFIX is defined as CONFIG_SYMBOL_PREFIX is a quoted
> string literal, so define __SYMBOL_NAME directly depending on
> CONFIG_SYMBOL_PREFIX.

I just pushed my modules-next tree to Linus, so hopefully the nightmare
is over soon!

Cheers,
Rusty.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


Re: [PATCH] linkage.h: fix build breakage due to symbol prefix handling

2013-05-01 Thread James Hogan
On 1 May 2013 22:43, Al Viro  wrote:
> On Wed, May 01, 2013 at 10:04:17PM +0100, James Hogan wrote:
>> Al's commit e1b5bb6d1236d4ad2084c53aa83dde7cdf6f8eea ("consolidate
>> cond_syscall and SYSCALL_ALIAS declarations") broke the build on
>> blackfin and metag due to the following code:
>>
>>   #ifndef SYMBOL_NAME
>>   #ifdef CONFIG_SYMBOL_PREFIX
>>   #define SYMBOL_NAME(x) CONFIG_SYMBOL_PREFIX ## x
>>   #else
>>   #define SYMBOL_NAME(x) x
>>   #endif
>>   #endif
>>   #define __SYMBOL_NAME(x) __stringify(SYMBOL_NAME(x))
>>
>> __stringify literally stringifies CONFIG_SYMBOL_PREFIX ##x, so you get
>> lines like this in kernel/sys_ni.s:
>>
>>   .weak CONFIG_SYMBOL_PREFIXsys_quotactl
>>   .set CONFIG_SYMBOL_PREFIXsys_quotactl,CONFIG_SYMBOL_PREFIXsys_ni_syscall
>>
>> The patches in Rusty's modules-next tree such as "CONFIG_SYMBOL_PREFIX:
>> cleanup." clean up the whole mess around symbol prefixes, so this patch
>> just attempts to fix the build in the mean time. The intermediate
>> definition of SYMBOL_NAME above isn't used and is incorrect when
>> CONFIG_SYMBOL_PREFIX is defined as CONFIG_SYMBOL_PREFIX is a quoted
>> string literal, so define __SYMBOL_NAME directly depending on
>> CONFIG_SYMBOL_PREFIX.
>
> Oh, hell...  Guys, my deep apologies - what happened is that this thing
> has been caught in -next, rebase done here (on top of Rusty's commit)
> and *not* pushed to linux-next.  Unfortunately, folks had been too polite
> and didn't keep kicking me - mistake, since the whole thing got forgotten ;-/
> Sigh...

No worries. Unfortunately after the tip of linux-next started working
again with Rusty's commit it sort of fell off my radar.

Cheers
James
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


Re: [PATCH] linkage.h: fix build breakage due to symbol prefix handling

2013-05-01 Thread Al Viro
On Wed, May 01, 2013 at 10:04:17PM +0100, James Hogan wrote:
> Al's commit e1b5bb6d1236d4ad2084c53aa83dde7cdf6f8eea ("consolidate
> cond_syscall and SYSCALL_ALIAS declarations") broke the build on
> blackfin and metag due to the following code:
> 
>   #ifndef SYMBOL_NAME
>   #ifdef CONFIG_SYMBOL_PREFIX
>   #define SYMBOL_NAME(x) CONFIG_SYMBOL_PREFIX ## x
>   #else
>   #define SYMBOL_NAME(x) x
>   #endif
>   #endif
>   #define __SYMBOL_NAME(x) __stringify(SYMBOL_NAME(x))
> 
> __stringify literally stringifies CONFIG_SYMBOL_PREFIX ##x, so you get
> lines like this in kernel/sys_ni.s:
> 
>   .weak CONFIG_SYMBOL_PREFIXsys_quotactl
>   .set CONFIG_SYMBOL_PREFIXsys_quotactl,CONFIG_SYMBOL_PREFIXsys_ni_syscall
> 
> The patches in Rusty's modules-next tree such as "CONFIG_SYMBOL_PREFIX:
> cleanup." clean up the whole mess around symbol prefixes, so this patch
> just attempts to fix the build in the mean time. The intermediate
> definition of SYMBOL_NAME above isn't used and is incorrect when
> CONFIG_SYMBOL_PREFIX is defined as CONFIG_SYMBOL_PREFIX is a quoted
> string literal, so define __SYMBOL_NAME directly depending on
> CONFIG_SYMBOL_PREFIX.

Oh, hell...  Guys, my deep apologies - what happened is that this thing
has been caught in -next, rebase done here (on top of Rusty's commit)
and *not* pushed to linux-next.  Unfortunately, folks had been too polite
and didn't keep kicking me - mistake, since the whole thing got forgotten ;-/
Sigh...
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/