summaryrefslogtreecommitdiffstats
path: root/mm/vmscan.c
diff options
context:
space:
mode:
authorAl Viro <viro@zeniv.linux.org.uk>2005-10-16 00:17:33 -0700
committerDavid S. Miller <davem@davemloft.net>2005-10-16 00:17:33 -0700
commit688ce17b8599abc548b406c00e4d18ae0dec954f (patch)
treec64c78c72bf9582c2dcc5a3455d6fe561c6e7085 /mm/vmscan.c
parente6850cce8f0fcb0e16b981f13cb9c69618bbdaf1 (diff)
downloadkernel-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