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
