Some architectures have symbol prefixes and set CONFIG_SYMBOL_PREFIX,
but this wasn't taken into account by the generic cond_syscall. It's
easy enough to fix in a generic fashion, so add the symbol prefix to
symbol names in cond_syscall when CONFIG_SYMBOL_PREFIX is set.
Signed-off-by: James Hogan <[email protected]>
---
include/asm-generic/unistd.h | 9 ++++++++-
1 files changed, 8 insertions(+), 1 deletions(-)
diff --git a/include/asm-generic/unistd.h b/include/asm-generic/unistd.h
index 2292d1a..c9a5ba4 100644
--- a/include/asm-generic/unistd.h
+++ b/include/asm-generic/unistd.h
@@ -924,7 +924,14 @@ __SYSCALL(__NR_fork, sys_ni_syscall)
* but it doesn't work on all toolchains, so we just do it by hand
*/
#ifndef cond_syscall
-#define cond_syscall(x) asm(".weak\t" #x "\n\t.set\t" #x ",sys_ni_syscall")
+#ifdef CONFIG_SYMBOL_PREFIX
+#define __SYMBOL_PREFIX CONFIG_SYMBOL_PREFIX
+#else
+#define __SYMBOL_PREFIX
+#endif
+#define cond_syscall(x) asm(".weak\t" __SYMBOL_PREFIX #x "\n\t" \
+ ".set\t" __SYMBOL_PREFIX #x "," \
+ __SYMBOL_PREFIX "sys_ni_syscall")
#endif
#endif /* __KERNEL__ */
--
1.7.2.3
On Friday 24 February 2012, James Hogan wrote:
> Some architectures have symbol prefixes and set CONFIG_SYMBOL_PREFIX,
> but this wasn't taken into account by the generic cond_syscall. It's
> easy enough to fix in a generic fashion, so add the symbol prefix to
> symbol names in cond_syscall when CONFIG_SYMBOL_PREFIX is set.
>
> Signed-off-by: James Hogan <[email protected]>
> ---
> include/asm-generic/unistd.h | 9 ++++++++-
> 1 files changed, 8 insertions(+), 1 deletions(-)
>
> diff --git a/include/asm-generic/unistd.h b/include/asm-generic/unistd.h
> index 2292d1a..c9a5ba4 100644
> --- a/include/asm-generic/unistd.h
> +++ b/include/asm-generic/unistd.h
> @@ -924,7 +924,14 @@ __SYSCALL(__NR_fork, sys_ni_syscall)
> * but it doesn't work on all toolchains, so we just do it by hand
> */
> #ifndef cond_syscall
> -#define cond_syscall(x) asm(".weak\t" #x "\n\t.set\t" #x ",sys_ni_syscall")
> +#ifdef CONFIG_SYMBOL_PREFIX
> +#define __SYMBOL_PREFIX CONFIG_SYMBOL_PREFIX
> +#else
> +#define __SYMBOL_PREFIX
> +#endif
> +#define cond_syscall(x) asm(".weak\t" __SYMBOL_PREFIX #x "\n\t" \
> + ".set\t" __SYMBOL_PREFIX #x "," \
> + __SYMBOL_PREFIX "sys_ni_syscall")
> #endif
Our trend is to move away from arch specific Kconfig symbols and __ARCH_HAS_*
macros towards just defining whatever you need in the architecture as an
override for the generic definition.
Just provide your own unistd.h that does
#define cond_syscall(x) asm(".weak\t." #x "\n\t.set\t." #x ",.sys_ni_syscall")
#include <asm-generic/unistd.h>
BTW, are you planning to submit arch/metag for inclusion? I've looked at
the code recently and it appears that you are on the right track overall,
and it shouldn't be too hard to get to the same quality level as
arch/openrisc.
Arnd
On Friday 24 February 2012, James Hogan wrote:
> Some architectures have symbol prefixes and set CONFIG_SYMBOL_PREFIX,
> but this wasn't taken into account by the generic cond_syscall. It's
> easy enough to fix in a generic fashion, so add the symbol prefix to
> symbol names in cond_syscall when CONFIG_SYMBOL_PREFIX is set.
>
> Signed-off-by: James Hogan <[email protected]>
> ---
> include/asm-generic/unistd.h | 9 ++++++++-
> 1 files changed, 8 insertions(+), 1 deletions(-)
>
> diff --git a/include/asm-generic/unistd.h b/include/asm-generic/unistd.h
> index 2292d1a..c9a5ba4 100644
> --- a/include/asm-generic/unistd.h
> +++ b/include/asm-generic/unistd.h
> @@ -924,7 +924,14 @@ __SYSCALL(__NR_fork, sys_ni_syscall)
> * but it doesn't work on all toolchains, so we just do it by hand
> */
> #ifndef cond_syscall
> -#define cond_syscall(x) asm(".weak\t" #x "\n\t.set\t" #x ",sys_ni_syscall")
> +#ifdef CONFIG_SYMBOL_PREFIX
> +#define __SYMBOL_PREFIX CONFIG_SYMBOL_PREFIX
> +#else
> +#define __SYMBOL_PREFIX
> +#endif
> +#define cond_syscall(x) asm(".weak\t" __SYMBOL_PREFIX #x "\n\t" \
> + ".set\t" __SYMBOL_PREFIX #x "," \
> + __SYMBOL_PREFIX "sys_ni_syscall")
> #endif
Our trend is to move away from arch specific Kconfig symbols and __ARCH_HAS_*
macros towards just defining whatever you need in the architecture as an
override for the generic definition.
Just provide your own unistd.h that does
#define cond_syscall(x) asm(".weak\t." #x "\n\t.set\t." #x ",.sys_ni_syscall")
#include <asm-generic/unistd.h>
BTW, are you planning to submit arch/metag for inclusion? I've looked at
the code recently and it appears that you are on the right track overall,
and it shouldn't be too hard to get to the same quality level as
arch/openrisc.
Arnd
Hi Arnd
Thanks for taking a look.
On 24/02/12 14:24, Arnd Bergmann wrote:
> On Friday 24 February 2012, James Hogan wrote:
>> Some architectures have symbol prefixes and set CONFIG_SYMBOL_PREFIX,
>> but this wasn't taken into account by the generic cond_syscall. It's
>> easy enough to fix in a generic fashion, so add the symbol prefix to
>> symbol names in cond_syscall when CONFIG_SYMBOL_PREFIX is set.
>>
>> Signed-off-by: James Hogan <[email protected]>
>> ---
>> include/asm-generic/unistd.h | 9 ++++++++-
>> 1 files changed, 8 insertions(+), 1 deletions(-)
>>
>> diff --git a/include/asm-generic/unistd.h b/include/asm-generic/unistd.h
>> index 2292d1a..c9a5ba4 100644
>> --- a/include/asm-generic/unistd.h
>> +++ b/include/asm-generic/unistd.h
>> @@ -924,7 +924,14 @@ __SYSCALL(__NR_fork, sys_ni_syscall)
>> * but it doesn't work on all toolchains, so we just do it by hand
>> */
>> #ifndef cond_syscall
>> -#define cond_syscall(x) asm(".weak\t" #x "\n\t.set\t" #x ",sys_ni_syscall")
>> +#ifdef CONFIG_SYMBOL_PREFIX
>> +#define __SYMBOL_PREFIX CONFIG_SYMBOL_PREFIX
>> +#else
>> +#define __SYMBOL_PREFIX
>> +#endif
>> +#define cond_syscall(x) asm(".weak\t" __SYMBOL_PREFIX #x "\n\t" \
>> + ".set\t" __SYMBOL_PREFIX #x "," \
>> + __SYMBOL_PREFIX "sys_ni_syscall")
>> #endif
>
> Our trend is to move away from arch specific Kconfig symbols and __ARCH_HAS_*
> macros towards just defining whatever you need in the architecture as an
> override for the generic definition.
>
> Just provide your own unistd.h that does
>
> #define cond_syscall(x) asm(".weak\t." #x "\n\t.set\t." #x ",.sys_ni_syscall")
> #include <asm-generic/unistd.h>
Okay, no problem.
> BTW, are you planning to submit arch/metag for inclusion? I've looked at
> the code recently and it appears that you are on the right track overall,
> and it shouldn't be too hard to get to the same quality level as
> arch/openrisc.
At this stage I'm just (in my own time) trying to get it closer to the
standard required for new architectures so that when the time comes
there's less to do.
I've been looking at your initial comments for other architecture
submissions and they've been very helpful, but if you do have any
arch/metag specific suggestions I'd certainly welcome them.
Thanks
James
On Friday 24 February 2012, James Hogan wrote:
> I've been looking at your initial comments for other architecture
> submissions and they've been very helpful, but if you do have any
> arch/metag specific suggestions I'd certainly welcome them.
I've had only a brief look. In general I recommend doing whatever
openrisc does, they are currently the best implementation we have.
In order to get the code merged, you will need to move probing
of on-chip buses to device trees rather than hardcoding the
platform devices, that is probably the largest amount of work
that is still needed unless you've done that already in a later
version.
Do you have a git tree or patch with the latest source code?
the only copy I could find is a 2.6.37 kernel inside of a huge
tarball.
Arnd
On 24/02/12 15:09, Arnd Bergmann wrote:
> On Friday 24 February 2012, James Hogan wrote:
>> I've been looking at your initial comments for other architecture
>> submissions and they've been very helpful, but if you do have any
>> arch/metag specific suggestions I'd certainly welcome them.
>
> I've had only a brief look. In general I recommend doing whatever
> openrisc does, they are currently the best implementation we have.
Okay, thanks for the tip.
> In order to get the code merged, you will need to move probing
> of on-chip buses to device trees rather than hardcoding the
> platform devices, that is probably the largest amount of work
> that is still needed unless you've done that already in a later
> version.
Okay, this is something I've been looking at.
> Do you have a git tree or patch with the latest source code?
> the only copy I could find is a 2.6.37 kernel inside of a huge
> tarball.
Sorry, but unfortunately that's the latest released version of the
kernel and I can't publish anything more recent at the moment.
Thanks
James
On Friday 24 February 2012 09:24:07 Arnd Bergmann wrote:
> On Friday 24 February 2012, James Hogan wrote:
> > Some architectures have symbol prefixes and set CONFIG_SYMBOL_PREFIX,
> > but this wasn't taken into account by the generic cond_syscall. It's
> > easy enough to fix in a generic fashion, so add the symbol prefix to
> > symbol names in cond_syscall when CONFIG_SYMBOL_PREFIX is set.
> >
> > include/asm-generic/unistd.h | 9 ++++++++-
> > 1 files changed, 8 insertions(+), 1 deletions(-)
> >
> > --- a/include/asm-generic/unistd.h
> > +++ b/include/asm-generic/unistd.h
> >
> > #ifndef cond_syscall
> > -#define cond_syscall(x) asm(".weak\t" #x "\n\t.set\t" #x
> > ",sys_ni_syscall")
> > +#ifdef CONFIG_SYMBOL_PREFIX
> > +#define __SYMBOL_PREFIX CONFIG_SYMBOL_PREFIX
> > +#else
> > +#define __SYMBOL_PREFIX
> > +#endif
> > +#define cond_syscall(x) asm(".weak\t" __SYMBOL_PREFIX #x "\n\t" \
> > + ".set\t" __SYMBOL_PREFIX #x "," \
> > + __SYMBOL_PREFIX "sys_ni_syscall")
> >
> > #endif
>
> Our trend is to move away from arch specific Kconfig symbols and
> __ARCH_HAS_* macros towards just defining whatever you need in the
> architecture as an override for the generic definition.
i don't see how __ARCH_HAS_xxx would help here. the symbol prefix is a string,
not a bool value. it's also already used by linux/export.h, asm-
generic/vmlinux.lds.h, and module code in scripts/.
> Just provide your own unistd.h that does
the point of asm-generic is so that arches don't have to keep copying &
pasting things that they really don't care about. James' proposed patch looks
good to me. it might be nice to go even further and add logic to a core
header so that CONFIG_SYMBOL_PREFIX is always defined ...
-mike
On Friday 24 February 2012, Mike Frysinger wrote:
> > Our trend is to move away from arch specific Kconfig symbols and
> > __ARCH_HAS_* macros towards just defining whatever you need in the
> > architecture as an override for the generic definition.
>
> i don't see how __ARCH_HAS_xxx would help here. the symbol prefix is a string,
> not a bool value. it's also already used by linux/export.h, asm-
> generic/vmlinux.lds.h, and module code in scripts/.
I gave __ARCH_HAS_xxx as an example because a lot of other places use that
to abstract architecture specific features, even if that wouldn't apply
here.
> > Just provide your own unistd.h that does
>
> the point of asm-generic is so that arches don't have to keep copying &
> pasting things that they really don't care about. James' proposed patch looks
> good to me. it might be nice to go even further and add logic to a core
> header so that CONFIG_SYMBOL_PREFIX is always defined ...
You are right. I did not realize that CONFIG_SYMBOL_PREFIX is an existing
symbol rather one that James defined for this purpose.
We actually have MODULE_SYMBOL_PREFIX providing the correct string
under a name that is not appropriate here. We can probably stick with
Jason's patch for now and add a more sophisticated logic if another
user of CONFIG_SYMBOL_PREFIX comes up.
So for Jason's patch:
Acked-by: Arnd Bergmann <[email protected]>
We could put that into the kernel now, but it's probably sufficient if
Jason keeps the patch with his others and submits it at the same time
when we get there.
Arnd
On Friday 24 February 2012, Arnd Bergmann wrote:
> We actually have MODULE_SYMBOL_PREFIX providing the correct string
> under a name that is not appropriate here. We can probably stick with
> Jason's patch for now and add a more sophisticated logic if another
> user of CONFIG_SYMBOL_PREFIX comes up.
>
> So for Jason's patch:
>
> Acked-by: Arnd Bergmann <[email protected]>
>
> We could put that into the kernel now, but it's probably sufficient if
> Jason keeps the patch with his others and submits it at the same time
> when we get there.
Sorry, I meant s/Jason/James/g
On Friday 24 February 2012 09:01:03 James Hogan wrote:
> Some architectures have symbol prefixes and set CONFIG_SYMBOL_PREFIX,
> but this wasn't taken into account by the generic cond_syscall. It's
> easy enough to fix in a generic fashion, so add the symbol prefix to
> symbol names in cond_syscall when CONFIG_SYMBOL_PREFIX is set.
Acked-by: Mike Frysinger <[email protected]>
-mike
On 24/02/12 16:38, Arnd Bergmann wrote:
> On Friday 24 February 2012, Arnd Bergmann wrote:
>> We actually have MODULE_SYMBOL_PREFIX providing the correct string
>> under a name that is not appropriate here. We can probably stick with
>> Jason's patch for now and add a more sophisticated logic if another
>> user of CONFIG_SYMBOL_PREFIX comes up.
>>
>> So for Jason's patch:
>>
>> Acked-by: Arnd Bergmann <[email protected]>
>>
>> We could put that into the kernel now, but it's probably sufficient if
>> Jason keeps the patch with his others and submits it at the same time
>> when we get there.
>
> Sorry, I meant s/Jason/James/g
np. Okay, I'll keep hold of it.
Thanks
James