On Tue 2026-04-07 16:09:39, Song Liu wrote: > On Tue, Apr 7, 2026 at 8:08 AM Petr Mladek <[email protected]> wrote: > [...] > > > + * @replace: replace tag: > > > + * = 0: Atomic replace is disabled; however, this patch > > > remains > > > + * eligible to be superseded by others. > > > > This is weird semantic. Which livepatch tag would be allowed to > > supersede it, please? > > > > Do we still need this category? > > > > > + * > 0: Atomic replace is enabled. Only existing patches > > > with a > > > + * matching replace tag will be superseded. > > > * @list: list node for global list of actively used patches > > > * @kobj: kobject for sysfs resources > > > * @obj_list: dynamic list of the object entries > > > @@ -137,7 +141,7 @@ struct klp_patch { > > > struct module *mod; > > > struct klp_object *objs; > > > struct klp_state *states; > > > - bool replace; > > > + unsigned int replace; > > > > This already breaks the backward compatibility by changing the type > > and semantic of this field. > > I was thinking if replace=0 means no replace, it is still backward > compatible. Did I miss something?
IMHO, the semantic of the no-replace mode would be strange if we introduce the hybrid mode. Especially, it would be strange when it can be replaced by any livepatch with random replace tag/set. Also it would just complicate the definition and detection of conflicts. I am going to provide more details in the reply to Yafang. Best Regards, Petr
