[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <4936c576-afdb-8aba-b79f-74a03c9702fe@huawei.com>
Date: Mon, 23 Sep 2024 10:29:31 +0800
From: Chen Zhongjin <chenzhongjin@...wei.com>
To: Josh Poimboeuf <jpoimboe@...nel.org>, Petr Mladek <pmladek@...e.com>
CC: <live-patching@...r.kernel.org>, <linux-kernel@...r.kernel.org>,
<x86@...nel.org>, Miroslav Benes <mbenes@...e.cz>, Joe Lawrence
<joe.lawrence@...hat.com>, Jiri Kosina <jikos@...nel.org>, Peter Zijlstra
<peterz@...radead.org>, Marcos Paulo de Souza <mpdesouza@...e.com>, Song Liu
<song@...nel.org>
Subject: Re: [RFC 00/31] objtool, livepatch: Livepatch module generation
On 2024/9/12 0:20, Josh Poimboeuf wrote:
...
>> Do not get me wrong. I do not expect that the upstream variant would
>> be feature complete from the beginning. I just want to get a picture
>> how far it is. The code will be maintained only when it would have
>> users. And it would have users only when it would be comparable or
>> better then kPatch.
>
> I agree it needs to be fully functional before merge, but only for x86.
>
> Red Hat (and Meta?) will start using it as soon as x86 support is ready,
> because IBT/LTO support is needed, which kpatch-build can't handle.
>
> Then there will be an intermediate period where both kpatch-build and
> klp-build are used and supported, until the other arches get ported
> over.
>
> So I think this should be merged once the x86 support is complete, as it
> will have users immediately for those who are running on x86 with IBT
> and/or LTO.
>
If this is merged on x86, we (Huawei) are interested to port it to other
arches such as arm64.
Previously for some arches (at least, arm64 has said) the
functionalities of objtool is not so attractive to merge. If klp-tool
is added, it will be reasonable to use objtool on other arches. Now we
have to put a lot of work to add klp for kernel and managing an
out-of-tree kpatch tool if we want klp on other arches.
Best Regards,
Chen
Powered by blists - more mailing lists