[Crash-utility] Re: makedumpfile question / request
----- "Ken'ichi Ohmichi" <oomichi(a)mxs.nes.nec.co.jp> wrote:
Hi Dave,
Dave Anderson wrote:
> Is there a reason that makedumpfile does not fill in the utsname structure
> in the compressed dumpfile's header?
Thank you for good point.
makedumpfile does not fill it because makedumpfile might not be able to
get kernel debug information (containing symbol system_utsname/init_uts_ns).
makedumpfile does not need kernel debug information if dump_level is 0 or 1,
and it does not read a new_utsname structure. (check_release() is not called.)
> The data structure does get read into a local new_utsname structure in the
> check_release() function, but it doesn't get saved and copied into the
> disk_dump_header in write_kdump_header().
>
> It would be helpful if that were in place as a quick ID for what the
> compressed dumpfile contains.
I feel that is worth.
How about saving new_utsname data into disk_dump_header only if dump_level
is 2 or bigger ?
Well, that's certainly preferable than the way it is now.
But let me ask you this...
Given that the init_uts_ns structure is always located in:
(1) unity-mapped memory, or in a mapped kernel region for x86_64/ia64, and
(2) that your initial() function calls get_phys_base() in all cases,
can't you just strip the relevant unity-mapping from the supplied
VMCOREINFO/init_uts_ns symbol value, apply the phys_base, and then
read it from the vmcore file?
Dave