lkml.org 
[lkml]   [2015]   [Jul]   [24]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: Revisiting patch dependencies
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


\
 
 \ /
  Last update: 2015-07-24 23:01    [W:0.061 / U:0.116 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site