makedumpfile question / request
anderson at redhat.com
Mon Apr 20 08:59:28 EDT 2009
----- "Ken'ichi Ohmichi" <oomichi at 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?
More information about the kexec