[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Message-Id: <20090113.181039.185575172.davem@davemloft.net>
Date: Tue, 13 Jan 2009 18:10:39 -0800 (PST)
From: David Miller <davem@...emloft.net>
To: reif@...thlink.net
Cc: sparclinux-owner@...r.kernel.org, akpm@...ux-foundation.org,
mingo@...e.hu, linux-kernel@...r.kernel.org
Subject: Re: sparc32 compile error: redefinition of
‘smp_call_function_single’
From: Robert Reif <reif@...thlink.net>
Date: Tue, 13 Jan 2009 20:40:04 -0500
> Todays git produces this compile error on sparc32:
>
> kernel/up.c:10: error: redefinition of ‘smp_call_function_single’
> /usr/src/sparc32/linux-2.6/arch/sparc/include/asm/smp_32.h:78: error: previous definition of ‘smp_call_function_single’ was here
Andrew, are you sure that Makefile condition for compiling
up.o is correct?
ifeq ($(CONFIG_USE_GENERIC_SMP_HELPERS),y)
obj-y += smp.o
else
obj-y += up.o
endif
If an arch doesn't use generic SMP helpers, there is no way
we should compile up.c into the tree when SMP.
This build regression was caused by:
commit 53ce3d9564908794ae7dd32969089b57df5fc098
Author: Andrew Morton <akpm@...ux-foundation.org>
Date: Fri Jan 9 12:27:08 2009 -0800
smp_call_function_single(): be slightly less stupid
If you do
smp_call_function_single(expression-with-side-effects, ...)
then expression-with-side-effects never gets evaluated on UP builds.
As always, implementing it in C is the correct thing to do.
While we're there, uninline it for size and possible header dependency
reasons.
And create a new kernel/up.c, as a place in which to put
uniprocessor-specific code and storage. It should mirror kernel/smp.c.
Signed-off-by: Andrew Morton <akpm@...ux-foundation.org>
Signed-off-by: Ingo Molnar <mingo@...e.hu>
Powered by blists - more mailing lists