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 -- To unsubscribe from this list: send the line "unsubscribe live-patching" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
