2.6.17-rc1-mm1: why did acpi_ns_build_external_path() become global?

2.6.17-rc1-mm1: why did acpi_ns_build_external_path() become global?

[Adrian Bunk]

On Tue, Apr 04, 2006 at 01:45:04AM -0700, Andrew Morton wrote:
>...
> Changes since 2.6.16-mm2:
> 
>  git-acpi.patch
>...
>  git trees.
>...

acpi_ns_build_external_path() became global but isn't used outside the 
file it's defined in.

Was this accidental or is a usage pending?

cu
Adrian

-- 

       "Is there not promise of rain?" Ling Tan asked suddenly out
        of the darkness. There had been need of rain for many days.
       "Only a promise," Lao Er said.
                                       Pearl S. Buck - Dragon Seed

2.6.17-rc1-mm1: drivers/acpi/numa.c compile error

[Adrian Bunk]

I'm getting the following compile error with CONFIG_ACPI_NUMA=y:

<--  snip  -->

...
  CC      drivers/acpi/numa.o
drivers/acpi/numa.c: In function 'acpi_numa_init':
drivers/acpi/numa.c:231: error: 'NR_NODE_MEMBLKS' undeclared (first use in this function)
drivers/acpi/numa.c:231: error: (Each undeclared identifier is reported only once
drivers/acpi/numa.c:231: error: for each function it appears in.)
make[2]: *** [drivers/acpi/numa.o] Error 1

<--  snip  -->

cu
Adrian

-- 

       "Is there not promise of rain?" Ling Tan asked suddenly out
        of the darkness. There had been need of rain for many days.
       "Only a promise," Lao Er said.
                                       Pearl S. Buck - Dragon Seed

Re: 2.6.17-rc1-mm1: drivers/acpi/numa.c compile error

[Andrew Morton]

Adrian Bunk <bunk@stusta.de> wrote:
>
> I'm getting the following compile error with CONFIG_ACPI_NUMA=y:
> 
> <--  snip  -->
> 
> ...
>   CC      drivers/acpi/numa.o
> drivers/acpi/numa.c: In function 'acpi_numa_init':
> drivers/acpi/numa.c:231: error: 'NR_NODE_MEMBLKS' undeclared (first use in this function)

I'm not quite sure how we managed that, but I guess
unify-pxm_to_node-and-node_to_pxm.patch triggered it?

Re: 2.6.17-rc1-mm1: drivers/acpi/numa.c compile error

[Adrian Bunk]

On Fri, Apr 07, 2006 at 01:59:37PM -0700, Andrew Morton wrote:
> Adrian Bunk <bunk@stusta.de> wrote:
> >
> > I'm getting the following compile error with CONFIG_ACPI_NUMA=y:
> > 
> > <--  snip  -->
> > 
> > ...
> >   CC      drivers/acpi/numa.o
> > drivers/acpi/numa.c: In function 'acpi_numa_init':
> > drivers/acpi/numa.c:231: error: 'NR_NODE_MEMBLKS' undeclared (first use in this function)
> 
> I'm not quite sure how we managed that, but I guess
> unify-pxm_to_node-and-node_to_pxm.patch triggered it?

Yes, obviously (I got this error on i386):

 config ACPI_NUMA
        bool "NUMA support"
        depends on NUMA
-       depends on (IA64 || X86_64)
+       depends on (X86_32 || IA64 || X86_64)
        default y if IA64_GENERIC || IA64_SGI_SN2


cu
Adrian

-- 

       "Is there not promise of rain?" Ling Tan asked suddenly out
        of the darkness. There had been need of rain for many days.
       "Only a promise," Lao Er said.
                                       Pearl S. Buck - Dragon Seed

Re: 2.6.17-rc1-mm1: drivers/acpi/numa.c compile error

[Randy.Dunlap]

On Sun, 9 Apr 2006 17:44:46 +0200 Adrian Bunk wrote:

> On Fri, Apr 07, 2006 at 01:59:37PM -0700, Andrew Morton wrote:
> > Adrian Bunk <bunk@stusta.de> wrote:
> > >
> > > I'm getting the following compile error with CONFIG_ACPI_NUMA=y:
> > > 
> > > <--  snip  -->
> > > 
> > > ...
> > >   CC      drivers/acpi/numa.o
> > > drivers/acpi/numa.c: In function 'acpi_numa_init':
> > > drivers/acpi/numa.c:231: error: 'NR_NODE_MEMBLKS' undeclared (first use in this function)
> > 
> > I'm not quite sure how we managed that, but I guess
> > unify-pxm_to_node-and-node_to_pxm.patch triggered it?
> 
> Yes, obviously (I got this error on i386):
> 
>  config ACPI_NUMA
>         bool "NUMA support"
>         depends on NUMA
> -       depends on (IA64 || X86_64)
> +       depends on (X86_32 || IA64 || X86_64)
>         default y if IA64_GENERIC || IA64_SGI_SN2

The new/fixed line should just be
	depends on X86 || IA64
since X86_32 and X86_64 both set X86.

---
~Randy

RE: 2.6.17-rc1-mm1: why did acpi_ns_build_external_path() become global?

[Moore, Robert]

This interface is public now because it is used in common/dsrestag.c

This is the problem as I see it:

We have a continuing issue where we have a bunch of ACPI components
(interpreter, table manager, resource manager, etc.) Depending on how
the pieces are put together, various sub-parts of the components are
used or not used, depending on the application. The kernel-level code is
integrated into many different operating systems. Each OS used a
different subset of the available external interfaces. Further, each of
the user-level applications (iASL compiler, AcpiExec utility, etc.) use
different interfaces.

In this case, it is the iASL compiler that is using build_external_path.

We could certainly go so far as to put each public interface into a
separate file, allowing each application (and host OS) to pick and
choose the exact interfaces it needs (and I have seen it done this
way.), but this leads to a huge number of small files and I'm not sure
we want this.

However, attempting to track all of this with extensive #ifdefs, etc. is
awkward and ugly at best and very difficult to maintain.

I'm open to suggestions.

Bob


> -----Original Message-----
> From: linux-acpi-owner@vger.kernel.org [mailto:linux-acpi-
> owner@vger.kernel.org] On Behalf Of Adrian Bunk
> Sent: Tuesday, April 04, 2006 9:30 AM
> To: Andrew Morton; Brown, Len
> Cc: linux-kernel@vger.kernel.org; linux-acpi@vger.kernel.org
> Subject: 2.6.17-rc1-mm1: why did acpi_ns_build_external_path() become
> global?
> 
> On Tue, Apr 04, 2006 at 01:45:04AM -0700, Andrew Morton wrote:
> >...
> > Changes since 2.6.16-mm2:
> >
> >  git-acpi.patch
> >...
> >  git trees.
> >...
> 
> acpi_ns_build_external_path() became global but isn't used outside the
> file it's defined in.
> 
> Was this accidental or is a usage pending?
> 
> cu
> Adrian
> 
> --
> 
>        "Is there not promise of rain?" Ling Tan asked suddenly out
>         of the darkness. There had been need of rain for many days.
>        "Only a promise," Lao Er said.
>                                        Pearl S. Buck - Dragon Seed
> 
> -
> To unsubscribe from this list: send the line "unsubscribe linux-acpi"
in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html