Date: Fri, 24 Jul 2015 22:44:22 +0200 (CEST)
From: Jiri Kosina <jkosina@suse.com>
To: Josh Poimboeuf <jpoimboe@redhat.com>
cc: Minfei Huang <mhuang@redhat.com>, sjenning@redhat.com, vojtech@suse.cz,
        live-patching@vger.kernel.org, linux-kernel@vger.kernel.org,
        Minfei Huang <mnfhuang@gmail.com>
Subject: Re: Revisiting patch dependencies
In-Reply-To: <20150723180702.GA3641@treble.redhat.com>
Message-ID: <alpine.LNX.2.00.1507242239240.925@pobox.suse.cz>
References: <1436950506-5252-1-git-send-email-mhuang@redhat.com> <20150722144004.GC23235@treble.redhat.com> <20150723040206.GA18136@dhcp-128-25.nay.redhat.com> <20150723180702.GA3641@treble.redhat.com>
User-Agent: Alpine 2.00 (LNX 1167 2008-08-23)
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: linux-kernel-owner@vger.kernel.org
Content-Length: 2530
Lines: 56

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 linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/