Re: [PATCH] kbuild: use -flive-patching when CONFIG_LIVEPATCH is enabled

[Joao Moreira]

On 12/20/18 12:33 AM, Miroslav Benes wrote:
> On Wed, 19 Dec 2018, Jiri Kosina wrote:
>
> > On Wed, 19 Dec 2018, Josh Poimboeuf wrote:
> >
> > > Also the commit message needs an analysis of the performance impacts.
> >
> > Agreed. Especially as it's expected (*) to be completely in the noise
> > particularly for the kernel, it'd be good to have that documented in the
> > changelog.
> >
> > (*) actually measured already for some subset of the IPA optimizations
>
> Ok, we can do that. I don't expect the results to be different from the
> last measurement as Jiri mentions. The sets of disabled optimizations are
> similar.
>
> I'll add it to v2.
>
> On Wed, 19 Dec 2018, Jiri Kosina wrote:
>
> > On Wed, 19 Dec 2018, Josh Poimboeuf wrote:
> >
> > > > > This option only makes sense for source-based patch generation, so isn't
> > > > > it a bit premature to make this change without proper source-based patch
> > > > > tooling?
> > > >
> > > > The reality is though that before the full-fledged patch tooling exists,
> > > > people are actually already writing livepatches by hand, so this option is
> > > > useful for them.
> > >
> > > Fair enough.
>
> Yes, that was the reason I sent it. It would not make sense to wait for
> the tooling in this case, because -flive-patching is useful even now,
> since there is a way to prepare livepatches without any tooling.
>
> > > Though, upstream, almost everybody seems to use kpatch-build, for which
> > > this patch doesn't help.  And people will continue to do so until we
> > > have decent source-based tooling.  Will the klp-convert patches be
> > > revived soon?
> >
> > Let me add Joao, who's working on that.
> >
> > Joao, I think you had something basically ready for upstream exposure,
> > right?
>
> I think that when Joao posted it a long time ago, the conclusion was that
> it would be better to wait for the source-based tooling and have the
> complete solution. I may misremember though.

Your memories match mine, Miroslav.

FTR, we recently integrated klp-convert to SLE. There were some fixes in 
comparison with the version which was submitted upstream, thus a v2 of 
the patches is necessary.

> If Josh thinks that it would be acceptable to have klp-convert merged even
> without the tooling, I'm all for it.
Of course I can work on that and I'll be glad to do so / submit this new 
version, if this is now something considered useful.

> We're about to start using it at SUSE and staying close to upstream would
> definitely be better.
>
> Miroslav