> > > At this point, I only see downsides of -flive-patching, at least until > > > we actually have real upstream code which needs it. > > > > Can you explain this? The option makes GCC to avoid optimizations which > > are difficult to detect and would make live patching unsafe. I consider it > > useful as it is, so if you shared the other downsides and what you meant > > by real upstream code, we could discuss it. > > Only SLES needs it right? Why inflict it on other livepatch users? By > "real upstream code" I mean there's no (documented) way to create live > patches using the method which relies on this flag. So I don't see any > upstream benefits for having it enabled. I'd put it differently. SLES and upstream need it, RHEL does not need it. Or anyone using kpatch-build. It is perfectly fine to prepare live patches just from the source code using upstream live patching infrastructure. After all, SLES is nothing else than upstream here. We were creating live patches manually for quite a long time and only recently we have been using Nicolai's klp-ccp automation (https://github.com/SUSE/klp-ccp). So, everyone using upstream directly relies on the flag, which seems to be a clear benefit to me. Reverting the patch would be a step back. Also I think we're moving in the right direction to make the life of upstream user easier with a proposal of klp-ccp and Petr's patch set to split live patch modules. It is a path from inconvenient to comfortable and not from impossible to possible. Miroslav
