On Fri 2019-02-15 16:29:55, Joe Lawrence wrote: > On 2/14/19 5:47 AM, Nicolai Stange wrote: > > Joe Lawrence <joe.lawrence@xxxxxxxxxx> writes: > > > - Do features need to be tightly coupled to callbacks? They are a > > > convenient tool to implement a policy, but I wonder if we lose > > > anything by moving this up to the klp_patch level and letting the core > > > handle it. (Like the versioning scheme.) > > > > If I'm understanding you correctly, you wonder whether having a > > klp_object member in klp_feature would be necessary or not, right? > > Yup. Instead we could have an API call to get/set features. > > > I think it doesn't matter much in these "safe upgrade" scenarios > > being discussed here. > > > > I have to admit though that I don't see the need for having the > > klp_features dynamic or "shadow variable like": I think we could embed > > those statically into klp_patch as well. > > > > > > > Features could still be stored in a list and the callbacks could get > > > access to current vs. this patch's feature set. They wouldn't be > > > dynamic, but then the API supporting that could drop out. > > > > Right, so during a transition, access to klp_features from the previous > > live patch would be possible only up to and including the pre-patch > > callback, correct? > > At least the ability to set them. Once we're past the pre-patch callback > stage, reading maybe useful for some purpose, but not transition reversal. I wonder why this limitation would be needed. In fact, I think that more natural would be to take over an existing state in post_patch() callback. It might even be necessary when both livepatches need different data and the replaced one need to get destroyed. Best Regards, Petr PS: I am sorry for the late reply. I have got knee deep in review of a huge printk-rework patchset, see https://lkml.kernel.org/r/20190212143003.48446-1-john.ogness@xxxxxxxxxxxxx Best Regards, Petr
