Am Montag, den 27.04.2009, 09:27 -0400 schrieb Dave Anderson:
> ----- "Michael Holzheu" <holzheu@xxxxxxxxxxxxxxxxxx> 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@xxxxxxxxxxxxxxxxxx>
> >
> > 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
--
Crash-utility mailing list
Crash-utility@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/crash-utility
