On 21. Aug 2019, at 20:31, Konrad Rzeszutek Wilk > wrote: On 8/21/19 4:19 AM, Pawel Wieczorkiewicz wrote: By default, in the quiescing zone, a hotpatch payload is applied with apply_payload() and reverted with revert_payload() functions. Both of the functions receive the payload struct pointer as a parameter. The functions are also a place where standard 'load' and 'unload' module hooks are executed. To increase hotpatching system's agility and provide more flexiable long-term hotpatch solution, allow to overwrite the default apply and revert action functions with hook-like supplied alternatives. The alternative functions are optional and the default functions are used by default. Since the alternative functions have direct access to the hotpatch payload structure, they can better control context of the 'load' and 'unload' hooks execution as well as exact instructions replacement workflows. They can be also easily extended to support extra features in the future. To simplify the alternative function generation move code responsible for payload and hotpatch region registration outside of the function. That way it is guaranteed that the registration step occurs even for newly supplied functions. This logic looks legit, but I was wondering if you would be up for a writing a small test-case(s) livepatch that would exercise these parts just to make sure nothing in the future would screw it up? Yes, I could do that. But, I would like to discuss (get guidelines about) the expected test coverage. With this sort of changes, there is an unlimited set of test-cases to be created. So, I would like to focus on a few most important. I am missing knowledge how these test cases are supposed to be used… hence the ask. Best Regards, Pawel Wieczorkiewicz Amazon Development Center Germany GmbH Krausenstr. 38 10117 Berlin Geschaeftsfuehrung: Christian Schlaeger, Ralf Herbrich Eingetragen am Amtsgericht Charlottenburg unter HRB 149173 B Sitz: Berlin Ust-ID: DE 289 237 879