makedumpfile question / request

[Dave Anderson]

----- "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?

Dave