diff mbox

[RFC] ARM: Export the CPU logical map to modules

Message ID 1359394444-16610-1-git-send-email-dave.martin@linaro.org
State New
Headers show

Commit Message

Dave Martin Jan. 28, 2013, 5:34 p.m. UTC
It is reasonable for loadable modules to be CPU topology aware
(particular examples include cpufreq and cpuidle drivers).

This patch exports __cpu_logical_map, so that modules can use the
cpu_logical_map() interface declared in <asm/smp_plat.h>.

Signed-off-by: Dave Martin <dave.martin@linaro.org>
---
If anyone has a strong view on whether this should be
EXPORT_SYMBOL_GPL(), I don't have a problem with changing
that.  I'm not sure of the precise etiquette here.
Certainly this does not feel like a very "public" interface.

Perhaps we should wrap this in a real function for export
to modules, rather than encouraging them to poke the
__cpu_logical_map[] array (albeit via a predefined macro).


 arch/arm/kernel/setup.c |    1 +
 1 files changed, 1 insertions(+), 0 deletions(-)

Comments

Dave Martin Feb. 7, 2013, 12:22 p.m. UTC | #1
Hi,

Does anyone have a comment on this?

Cheers
---Dave

On Mon, Jan 28, 2013 at 05:34:04PM +0000, Dave Martin wrote:
> It is reasonable for loadable modules to be CPU topology aware
> (particular examples include cpufreq and cpuidle drivers).
> 
> This patch exports __cpu_logical_map, so that modules can use the
> cpu_logical_map() interface declared in <asm/smp_plat.h>.
> 
> Signed-off-by: Dave Martin <dave.martin@linaro.org>
> ---
> If anyone has a strong view on whether this should be
> EXPORT_SYMBOL_GPL(), I don't have a problem with changing
> that.  I'm not sure of the precise etiquette here.
> Certainly this does not feel like a very "public" interface.
> 
> Perhaps we should wrap this in a real function for export
> to modules, rather than encouraging them to poke the
> __cpu_logical_map[] array (albeit via a predefined macro).
> 
> 
>  arch/arm/kernel/setup.c |    1 +
>  1 files changed, 1 insertions(+), 0 deletions(-)
> 
> diff --git a/arch/arm/kernel/setup.c b/arch/arm/kernel/setup.c
> index 3f6cbb2..1b9e5bf 100644
> --- a/arch/arm/kernel/setup.c
> +++ b/arch/arm/kernel/setup.c
> @@ -428,6 +428,7 @@ void cpu_init(void)
>  }
>  
>  int __cpu_logical_map[NR_CPUS];
> +EXPORT_SYMBOL(__cpu_logical_map);
>  
>  void __init smp_setup_processor_id(void)
>  {
> -- 
> 1.7.4.1
>
Nicolas Pitre Feb. 7, 2013, 8:05 p.m. UTC | #2
On Thu, 7 Feb 2013, Dave Martin wrote:

> Hi,
> 
> Does anyone have a comment on this?

As you say, I'd be tempted to export some accessor with well defined 
semantic meaning instead.



> 
> Cheers
> ---Dave
> 
> On Mon, Jan 28, 2013 at 05:34:04PM +0000, Dave Martin wrote:
> > It is reasonable for loadable modules to be CPU topology aware
> > (particular examples include cpufreq and cpuidle drivers).
> > 
> > This patch exports __cpu_logical_map, so that modules can use the
> > cpu_logical_map() interface declared in <asm/smp_plat.h>.
> > 
> > Signed-off-by: Dave Martin <dave.martin@linaro.org>
> > ---
> > If anyone has a strong view on whether this should be
> > EXPORT_SYMBOL_GPL(), I don't have a problem with changing
> > that.  I'm not sure of the precise etiquette here.
> > Certainly this does not feel like a very "public" interface.
> > 
> > Perhaps we should wrap this in a real function for export
> > to modules, rather than encouraging them to poke the
> > __cpu_logical_map[] array (albeit via a predefined macro).
> > 
> > 
> >  arch/arm/kernel/setup.c |    1 +
> >  1 files changed, 1 insertions(+), 0 deletions(-)
> > 
> > diff --git a/arch/arm/kernel/setup.c b/arch/arm/kernel/setup.c
> > index 3f6cbb2..1b9e5bf 100644
> > --- a/arch/arm/kernel/setup.c
> > +++ b/arch/arm/kernel/setup.c
> > @@ -428,6 +428,7 @@ void cpu_init(void)
> >  }
> >  
> >  int __cpu_logical_map[NR_CPUS];
> > +EXPORT_SYMBOL(__cpu_logical_map);
> >  
> >  void __init smp_setup_processor_id(void)
> >  {
> > -- 
> > 1.7.4.1
> > 
>
Dave Martin Feb. 8, 2013, 11:33 a.m. UTC | #3
On Thu, Feb 07, 2013 at 03:05:03PM -0500, Nicolas Pitre wrote:
> On Thu, 7 Feb 2013, Dave Martin wrote:
> 
> > Hi,
> > 
> > Does anyone have a comment on this?
> 
> As you say, I'd be tempted to export some accessor with well defined 
> semantic meaning instead.

I think I agree...

Modules definitely shouldn't easily be able to write cpu_logical_map.

I'll rework something and repost.

Cheers
---Dave

> 
> 
> 
> > 
> > Cheers
> > ---Dave
> > 
> > On Mon, Jan 28, 2013 at 05:34:04PM +0000, Dave Martin wrote:
> > > It is reasonable for loadable modules to be CPU topology aware
> > > (particular examples include cpufreq and cpuidle drivers).
> > > 
> > > This patch exports __cpu_logical_map, so that modules can use the
> > > cpu_logical_map() interface declared in <asm/smp_plat.h>.
> > > 
> > > Signed-off-by: Dave Martin <dave.martin@linaro.org>
> > > ---
> > > If anyone has a strong view on whether this should be
> > > EXPORT_SYMBOL_GPL(), I don't have a problem with changing
> > > that.  I'm not sure of the precise etiquette here.
> > > Certainly this does not feel like a very "public" interface.
> > > 
> > > Perhaps we should wrap this in a real function for export
> > > to modules, rather than encouraging them to poke the
> > > __cpu_logical_map[] array (albeit via a predefined macro).
> > > 
> > > 
> > >  arch/arm/kernel/setup.c |    1 +
> > >  1 files changed, 1 insertions(+), 0 deletions(-)
> > > 
> > > diff --git a/arch/arm/kernel/setup.c b/arch/arm/kernel/setup.c
> > > index 3f6cbb2..1b9e5bf 100644
> > > --- a/arch/arm/kernel/setup.c
> > > +++ b/arch/arm/kernel/setup.c
> > > @@ -428,6 +428,7 @@ void cpu_init(void)
> > >  }
> > >  
> > >  int __cpu_logical_map[NR_CPUS];
> > > +EXPORT_SYMBOL(__cpu_logical_map);
> > >  
> > >  void __init smp_setup_processor_id(void)
> > >  {
> > > -- 
> > > 1.7.4.1
> > > 
> >
diff mbox

Patch

diff --git a/arch/arm/kernel/setup.c b/arch/arm/kernel/setup.c
index 3f6cbb2..1b9e5bf 100644
--- a/arch/arm/kernel/setup.c
+++ b/arch/arm/kernel/setup.c
@@ -428,6 +428,7 @@  void cpu_init(void)
 }
 
 int __cpu_logical_map[NR_CPUS];
+EXPORT_SYMBOL(__cpu_logical_map);
 
 void __init smp_setup_processor_id(void)
 {