[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <1b6ee81b-5699-a1cc-9a85-02df0eeaed12@redhat.com>
Date: Tue, 26 Mar 2019 16:53:12 -0400
From: Joe Lawrence <joe.lawrence@...hat.com>
To: Joao Moreira <jmoreira@...e.de>, Miroslav Benes <mbenes@...e.cz>
Cc: live-patching@...r.kernel.org, pmladek@...e.cz, jikos@...e.cz,
nstange@...e.de, jpoimboe@...hat.com, khlebnikov@...dex-team.ru,
jeyu@...nel.org, matz@...e.de, linux-kernel@...r.kernel.org,
yamada.masahiro@...ionext.com, linux-kbuild@...r.kernel.org,
michal.lkml@...kovi.net
Subject: Re: [PATCH v2 2/8] kbuild: Support for Symbols.list creation
On 3/26/19 2:13 PM, Joao Moreira wrote:
>
>
> On 3/26/19 1:15 PM, Joe Lawrence wrote:
>>
>> Hi Joao,
>>
>> This change seems to work okay for (again) single object modules, but
>> I'm having issues with multi-object modules.
>>
>
> Hi Joe, thanks for the sources, this made everything much easier in my
> side :)
>
> In the patch below I change a little bit the interface used to inform
> kbuild that a module is a livepatch. Instead of defining the flag
> LIVEPATCH_ per .o file, we define it per module (what actually makes
> much more sense). We later use $(basetarget) in the Makefile for
> checking the flags. By doing so, and invoking cmd_livepatch both from
> the $(single-used-m) and $(multi-used-m) we ensure that the .livepatch
> file is created for each module, what later in the pipeline flags the
> invocation of klp-convert.
>
> I tested the following patch with the sources you provided (with little
> modifications, removing the .o from the LIVEPATCH_ definitions and using
> the module name instead of the object names), achieving successful
> compilation and conversion. I also tested against the sample
> livepatches, thus I think it might be ok now.
Cool thanks for taking a look -- I can confirm that the toy code I sent
over builds with those modifications and so does the sample and selftest
I was working on. I'll set about refactoring that klp-convert selftest
to combine .o files into a more compact module.
> Do you think we can go this way to solve the problem in v3?
Yeah, I'll add it to the list of patches to squash for v3.
Thanks,
-- Joe
Powered by blists - more mailing lists