[lkml]   [2018]   [Mar]   [2]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [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.


-- Joe

 \ /
  Last update: 2018-03-02 23:09    [W:0.098 / U:5.600 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site