diff options
author | Al Viro <viro@zeniv.linux.org.uk> | 2005-10-16 00:17:33 -0700 |
---|---|---|
committer | David S. Miller <davem@davemloft.net> | 2005-10-16 00:17:33 -0700 |
commit | 688ce17b8599abc548b406c00e4d18ae0dec954f (patch) | |
tree | c64c78c72bf9582c2dcc5a3455d6fe561c6e7085 /mm/vmscan.c | |
parent | e6850cce8f0fcb0e16b981f13cb9c69618bbdaf1 (diff) | |
download | kernel-crypto-688ce17b8599abc548b406c00e4d18ae0dec954f.tar.gz kernel-crypto-688ce17b8599abc548b406c00e4d18ae0dec954f.tar.xz kernel-crypto-688ce17b8599abc548b406c00e4d18ae0dec954f.zip |
[PATCH]: highest_possible_processor_id() has to be a macro
... 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>
Signed-off-by: David S. Miller <davem@davemloft.net>
Diffstat (limited to 'mm/vmscan.c')
0 files changed, 0 insertions, 0 deletions