----- "Ken'ichi Ohmichi" <oomichi@xxxxxxxxxxxxxxxxx> 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 -- Crash-utility mailing list Crash-utility@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/crash-utility
