Am Montag, den 27.04.2009, 09:27 -0400 schrieb Dave Anderson:
----- "Michael Holzheu" <holzheu(a)linux.vnet.ibm.com>
wrote:
> Hi Dave,
>
> I found some time to fix the cpu_map issue in 2.6.29.
> Here my proposal:
Thanks, man -- much appreciated...
> From: Michael Holzheu <holzheu(a)linux.vnet.ibm.com>
>
> In Linux 2.6.29 the cpu_(online, possible, present, active)_map global variables
> have been moved to cpu_(...)_mask variables that are pointers to structures
> with bitmaps now. This patch allows crash to work with the new variables.
>
> Note: The cpu_map_size() function now only uses STRUCT_SIZE("cpumask_t")
> to get the size of the cpu map. I removed the get_symbol_type() call
> since STRUCT_SIZE("cpumask_t") should always work.
>
> Correct me if I am wrong here!
Actually, this would break backwards compatibility. The "cpu_online_map"
used to be an "unsigned long", back when NR_CPUS was hardwired to 32.
So the get_symbol_type() is used to differentiate between that type and
its current invocation as a variably-sized cpumask_t struct based upon
NR_CPUS.
So yes, while STRUCT_SIZE("cpumask_t") would always be appropriate for that
data type, it would fail for the older kernel types which don't use it.
So if for older kernels it was an unsigned long, the function should
work:
+static int
+cpu_map_size(void)
+{
+ int len;
+
+ len = STRUCT_SIZE("cpumask_t");
+ if (len < 0)
+ return sizeof(ulong);
+ else
+ return len;
+}
Michael