> Ok - associating the "atomic replace" with the patch itself makes sense to me. > It would also basically work, I think with the patch I proposed except for the > case where the the "atomic replace" was on top of several non-"atomic replace" > patches. The reason is that the "atomic replace" I posted looks back 1 patch > to see what it needs to replace (assuming all patches are in atomic replace > mode). So instead of just looking back 1 patch, it could 'look back' and make > sure it was replacing all previously loaded patches.
Yes, this should not be a problem to implement with the current code. But I must say I am not entirely happy with the code as it is. The big advantage is that there are almost no changes to the consistency model. Almost everything is created and allocated during the initialization and the patch then looks ordinary. The current code can handle it smoothly. "Dynamic" superstructure is what I am not happy with. It is too complicated in my opinion. On the other hand I don't see a simple way out now. 1. We can try to make your code "nicer". 2. The main problem is that all user structures (klp_func, klp_object, klp_patch) are statically allocated in a kernel module. You need to add dynamically allocated structures, which is not easy. We can either change everything to dynamic allocation, or make everything static. As far as the former is concerned, we've been down that road IIRC. It didn't end up well. Is the latter even possible? 3. We could bypass everything and register special no-op fops to each reverted function. Those could be held and handled separately. It could be simpler, but it might be problematic to deal with the consistency model interaction. Thoughts? Regards, Miroslav
