[PATCH] highest_possible_processor_id() has to be a macro

[PATCH] highest_possible_processor_id() has to be a macro

[Al Viro]

	... otherwise, things like alpha and sparc64 break and break
badly.  They define cpu_possible_map to something else in smp.h
*AFTER* having included cpumask.h.

	If that puppy is a macro, expansion will happen at the actual
caller, when we'd already seen #define cpu_possible_map ... and we will
get the right thing used.

	As an inline helper it will be tokenized before we get to that
define and that's it; no matter what we define later, it won't affect
anything.  We get modules with dependency on cpu_possible_map instead
of the right symbol (phys_cpu_present_map in case of sparc64), or outright
link errors if they are built-in.

Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
----
diff -urN RC14-rc4-git4-base/include/linux/cpumask.h current/include/linux/cpumask.h
--- RC14-rc4-git4-base/include/linux/cpumask.h	2005-10-15 16:21:34.000000000 -0400
+++ current/include/linux/cpumask.h	2005-10-15 19:46:34.000000000 -0400
@@ -393,15 +393,13 @@
 #define for_each_present_cpu(cpu) for_each_cpu_mask((cpu), cpu_present_map)
 
 /* Find the highest possible smp_processor_id() */
-static inline unsigned int highest_possible_processor_id(void)
-{
-	unsigned int cpu, highest = 0;
-
-	for_each_cpu_mask(cpu, cpu_possible_map)
-		highest = cpu;
-
-	return highest;
-}
+#define highest_possible_processor_id() \
+({ \
+	unsigned int cpu, highest = 0; \
+	for_each_cpu_mask(cpu, cpu_possible_map) \
+		highest = cpu; \
+	highest; \
+})
 
 
 #endif /* __LINUX_CPUMASK_H */

Re: [PATCH] highest_possible_processor_id() has to be a macro

[David S. Miller]

From: Al Viro <viro@ftp.linux.org.uk>
Date: Sun, 16 Oct 2005 00:51:12 +0100

> 	... otherwise, things like alpha and sparc64 break and break
> badly.  They define cpu_possible_map to something else in smp.h
> *AFTER* having included cpumask.h.

So ugly...

But, it's the best fix for now.

Longer term we might want to make an asm/cpumask.h that can
help allow the platforms to cleanly say "well, mask X is
equivalent to Y, so only instantiate X and define Y to X"
which is all that these two platforms are trying to accomplish.

If you don't support cpu hotplug, present == possible afterall.

Re: [PATCH] highest_possible_processor_id() has to be a macro

[Herbert Xu]

David S. Miller <davem@davemloft.net> wrote:
> 
> So ugly...
> 
> But, it's the best fix for now.
> 
> Longer term we might want to make an asm/cpumask.h that can
> help allow the platforms to cleanly say "well, mask X is
> equivalent to Y, so only instantiate X and define Y to X"
> which is all that these two platforms are trying to accomplish.

The other thing you could is have an inline function called
highest_processor_id (or perhaps last_cpu) that calculates the
biggest CPU ID for any map and then define highest_possible_processor_id
as a macro that just calls the function with the right arguments.

Cheers,
-- 
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt

Re: [PATCH] highest_possible_processor_id() has to be a macro

[Al Viro]

On Sun, Oct 16, 2005 at 12:16:49AM -0700, David S. Miller wrote:
> From: Al Viro <viro@ftp.linux.org.uk>
> Date: Sun, 16 Oct 2005 00:51:12 +0100
> 
> > 	... otherwise, things like alpha and sparc64 break and break
> > badly.  They define cpu_possible_map to something else in smp.h
> > *AFTER* having included cpumask.h.
> 
> So ugly...
> 
> But, it's the best fix for now.
> 
> Longer term we might want to make an asm/cpumask.h that can
> help allow the platforms to cleanly say "well, mask X is
> equivalent to Y, so only instantiate X and define Y to X"

Indeed, but playing with moving stuff from smp.h is definitely post-2.6.14
fodder...