Hi Michael,
I made a few other changes to your cpu map/mask patch:
- cpu_map_size() has been changed to use the symbol-name-creation
scheme as cpu_map_addr() in order to absolutely maintain the
backwards-compatibility issue brought up by Robin. So if the
old symbol names still exist, the code does exactly the same
thing that it used to.
- Your changes to get_cpus_present() and get_cpus_possible() were
incomplete because they were still using the hardwired "cpus_present_map"
and "cpus_possible_map" symbols.
- I didn't change the s390.c and s390x.c s390[x]_get_smp_cpus()
functions beyond what you did, but I think they should be
changed to use get_cpus_online() instead of the way they
are doing it now. As it is now, they are restricting themselves
to the number of cpu bits in a per-arch long. If the
s390 CONFIG_NR_CPUS can exceed 32, or the s390x CONFIG_NR_CPUS
can exceed 64, then those two functions are incorrect.
If the architecture limits them to 32/64, then I suppose the
way it's done now is OK. That's your call...
Also, the attached patch contains the changes for searching
for kernel module debuginfo files in the same directory tree
specified with "mod -S <directory>". Alternatively there
is a new "crash --mod <directory>" command line option, such
that "mod -S" with no directory argument will default to
searching the command-line specified directory.
Anyway, I've only tested this on older kernels that still have
the "cpu_xxxx_map" symbols. Can you test the patch on new
kernels? And also let me know whether the s390[x] functions
should be updated.
Thanks,
Dave