On Thu, 23 Jul 2015, Josh Poimboeuf wrote: > a) Don't allow dependencies between patches. Instead all dependencies > must be contained within the patch itself. So patch A and patch B > are combined into a single patch AB. If, later, a new patch C is > needed, which also depends on A, then create a new cumulative patch > ABC which replaces AB. > > Note there's no way to enforce the fact there are no dependencies, > because they can be hidden. So it would just have to be a documented > rule that the patch author must follow, as part of the (yet to be > written) patch creation guidelines. This actually isn't a big deal > because there are several other (still undocumented) rules the patch > author must already follow. > > This would mean that klp code can assume there are no dependencies, > and so patch stacking would no longer be necessary. We'd probably > have to rework the ops->func_stack code a bit so that it's ordered by > when the patches were registered instead of when they were enabled, > so that disabling and re-enabling an older patch wouldn't override a > newer cumulative one which replaces it. > > b) Create a way for the patch author to specify explicit patch > dependencies. > > Note that both options a and b delegate responsibility to the patch > author to ensure that dependencies are handled appropriately. Ultimately > I don't think there's any way around that. > > My vote would be option a for now, by removing patch stacking and > documenting the guidelines. With the eventual possibility of adding b > if needed. As a data point, option (A) more or less describes the way how we in SUSE are distributing the actual live patches -- i.e. there is always a single cummulative patch package, that contains all the patches "squashed" together. It's a nice property of kGraft-like patching that the time required for the patching to finish doesn't depend on the number of functions being patched (because it's O(#processess_in_kernel)). That being said, I am also for option (A), but we have to keep in mind that time needed by some consistency models (those which are O(#patched_functions)) to finalize might be negatively affected by it. Thanks, -- Jiri Kosina SUSE Labs -- To unsubscribe from this list: send the line "unsubscribe live-patching" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
