On Wed, May 27, 2026 at 2:28 AM Song Liu <[email protected]> wrote: > > On Tue, May 26, 2026 at 3:35 AM Petr Mladek <[email protected]> wrote: > [...] > > > I wonder whether we should have "replace_set = 0" means no replace. > > > This will simplify the transition for users of the existing replace=false > > > option. I would like to hear other folks' thoughts on this. > > > > I would find this confusing. Also it would complicate the code. > > Agreed with your assessment of the scenario. > > > I always considered the "replace" and "no replace" mode as two > > separate worlds: > > > > + people using many "no replace" livepatches > > My only concern is that we are adding more burden to these users. > Before replace_set, they just use 0 for all the live patches.
The only valid use case for setting this to 0 is to keep certain livepatches persistent on the system. Without replace_set, developers are forced to disable replacement entirely. With replace_set, however, they have a better, more selective option to keep specific livepatches persistent. Therefore, I don't see this new semantic as an issue. On the other hand, the new klp-build tool already requires developers to significantly refactor their livepatch building and deployment systems, so adapting to this new semantic shouldn't be an additional burden. > With > replace_set, they will have to use some mechanism to assign a > unique replace_set for each livepatch. > > I don't know how many users are in this world. If there aren't many > users, we can ignore this case. > > > + people always using atomic replace > > OTOH, these users don't need much change. They will just use > replace_set = 1 for all live patches. > > Note that, I am not proposing to have replace_set = 1 to replace > all live patches. It only needs to replace other live patches with > replace_set = 1. The only change I am proposing (debating) here > is to have replace_set = 0 as "no replace". However, if this still > feels too confusing, or there are NOT many users in the "no > replace" world, we can safely ignore this. -- Regards Yafang
