[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <069122bb-15e6-61f6-e98c-07b356a12942@redhat.com>
Date: Fri, 2 Mar 2018 17:08:05 -0500
From: Joe Lawrence <joe.lawrence@...hat.com>
To: Petr Mladek <pmladek@...e.com>
Cc: Miroslav Benes <mbenes@...e.cz>, live-patching@...r.kernel.org,
linux-kernel@...r.kernel.org, Josh Poimboeuf <jpoimboe@...hat.com>,
Jessica Yu <jeyu@...nel.org>, Jiri Kosina <jikos@...nel.org>,
Jason Baron <jbaron@...mai.com>,
Evgenii Shatokhin <eshatokhin@...tuozzo.com>
Subject: Re: [PATCH v0 2/3] livepatch: update documentation/samples for
callbacks
On 03/02/2018 06:11 AM, Petr Mladek wrote:
> On Tue 2018-02-27 09:58:40, Joe Lawrence wrote:
>> In my mind, atomic replace is the mechanism that forces patching to be
>> cumulative. Perhaps this is too strict? Are there other use-cases for
>> atomic-replace?
>
> Jason talked about using the atomic replace to get rid of any
> existing livepatches and adding another changes instead. The changes
> in the old and the new patch might be unrelated. They simply do
> not want to mind what was there before. The term "atomic replace"
> fits perfectly for this usecase.
>
> My understanding is that cumulative patches do similar thing.
> But the old and new patches should be related. In particular,
> any new patch should include most changes from the older one.
> The only exception is when an old change was wrong and we do
> not want it anymore.
Yes, I can see the semantic difference between these cases. In my mind,
I am tainted by an understanding of the implementation... so I lazily
optimized both cases under a common terminology.
That said, you're right about potential confusion, so I'll update the
example and docs to remove references to "cumulative" and just call it
"atomic-replace" :)
> PS: I did not added these patches to v9 of the atomic replace
> patchset. It was already big enough. And I hope that v9 might
> be final. In addition, there are no conflicts on the touched
> files side.
I can continue to update as a separate patchset if that helps the the
other patchset reach a quicker conclusion.
As far as licensing, I don't mind modifying for SPDX tags if that's the
way we want to go.
Thanks,
-- Joe
Powered by blists - more mailing lists