On 1/11/2019 7:33 AM, Borislav Petkov wrote: > On Thu, Jan 10, 2019 at 08:19:43PM +0800, Lianbo Jiang wrote: >> +init_uts_ns.name.release >> +------------------------ >> + >> +The version of the Linux kernel. Used to find the corresponding source >> +code from which the kernel has been built. >> + > > ... > >> + >> +init_uts_ns >> +----------- >> + >> +This is the UTS namespace, which is used to isolate two specific >> +elements of the system that relate to the uname(2) system call. The UTS >> +namespace is named after the data structure used to store information >> +returned by the uname(2) system call. >> + >> +User-space tools can get the kernel name, host name, kernel release >> +number, kernel version, architecture name and OS type from it. > > Already asked this but no reply so lemme paste my question again: > > "And this document already fulfills its purpose - those two vmcoreinfo > exports are redundant and the first one can be removed. > > And now that we agreed that VMCOREINFO is not an ABI and is very tightly > coupled to the kernel version, init_uts_ns.name.release can be removed, > yes? > > Or is there anything speaking against that?" As for makedumpfile, it will be not impossible to remove the init_uts_ns.name.relase (OSRELEASE), but some fixes are needed. Because historically OSRELEASE has been a kind of a mandatory entry in vmcoreinfo from the beginning of vmcoreinfo, so makedumpfile uses its existence to check whether a vmcoreinfo is sane. Also, I think crash also will need to be fixed if it is removed. So I hope it will be left as it is. Thanks, Kazu _______________________________________________ kexec mailing list kexec@xxxxxxxxxxxxxxxxxxx http://lists.infradead.org/mailman/listinfo/kexec
