[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <93c1969f-dcc7-4e34-75ff-b14f2ec15269@redhat.com>
Date: Mon, 14 Jan 2019 09:52:14 +0800
From: lijiang <lijiang@...hat.com>
To: Borislav Petkov <bp@...en8.de>
Cc: linux-kernel@...r.kernel.org, kexec@...ts.infradead.org,
tglx@...utronix.de, mingo@...hat.com, x86@...nel.org,
akpm@...ux-foundation.org, bhe@...hat.com, dyoung@...hat.com,
k-hagio@...jp.nec.com, anderson@...hat.com,
linux-doc@...r.kernel.org
Subject: Re: [PATCH 1/2 v6] kdump: add the vmcoreinfo documentation
在 2019年01月11日 20:33, Borislav Petkov 写道:
> 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?"
>
Sorry for this, that is my mistake. Thanks for your reminder.
I agree on your point of view. But i forgot that i should remove this variable
in this post.
I would like to remove this variable and post again.
Thanks.
Lianbo
Powered by blists - more mailing lists