Re: livepatching tree for linux-next

From: Stephen Rothwell
Date: Thu Dec 25 2014 - 23:56:45 EST

Hi Jiri,

On Tue, 23 Dec 2014 09:10:56 -0600 Josh Poimboeuf <jpoimboe@xxxxxxxxxx> wrote:
> On Tue, Dec 23, 2014 at 01:46:07AM -0800, Christoph Hellwig wrote:
> > On Mon, Dec 22, 2014 at 08:52:02PM +0100, Jiri Kosina wrote:
> > >
> > > a substantial amount of work has been invested into abstracing "Live
> > > Patching" core functionality out of the already existing implementations,
> > > so that further improvements can be built on top of it in incremental
> > > steps.
> > >
> > > The core functionality (which is self-contained) now works and has been
> > > Reviewed/Acked by both interested parties (i.e. people working on kPatch
> > > and kGraft) and agreed to be a common ground on which further development
> > > will happen.
> > >
> > > We plan to send a pull request for 3.20, therefore I'd like to ask you to
> > > include 'for-next' branch of
> >
> > This is still missing the actual patch generators, which should be
> > merged together with the code, otherwise we'll get a mess with forever
> > out of tree tools like systemtap again.
> Well, a patch generator isn't required. You can build a patch module
> from source with kbuild, just like you would for any other kernel
> module. This is what kGraft already does today. For example:
> We do want to add a generator, but there are two of them out there that
> need to be converged. It doesn't make sense to do that work until we
> have first converged the rest of the stack (namely, consistency models).
> That's our next step.
> The current code is by no means a final product, but it's still quite
> useful already.

OK, I have added this from today but if it becomes an issue, I will
drop it again. Lets see how it goes.

Thanks for adding your subsystem tree as a participant of linux-next. As
you may know, this is not a judgment of your code. The purpose of
linux-next is for integration testing and to lower the impact of
conflicts between subsystems in the next merge window.

You will need to ensure that the patches/commits in your tree/series have
* submitted under GPL v2 (or later) and include the Contributor's
* posted to the relevant mailing list,
* reviewed by you (or another maintainer of your subsystem tree),
* successfully unit tested, and
* destined for the current or next Linux merge window.

Basically, this should be just what you would send to Linus (or ask him
to fetch). It is allowed to be rebased if you deem it necessary.

Stephen Rothwell

Attachment: pgpPnKKC1L5RJ.pgp
Description: OpenPGP digital signature