From: Josh Poimboeuf <jpoimboe@redhat.com>
To: Christoph Hellwig <hch@infradead.org>
Cc: Jiri Kosina <jkosina@suse.cz>,
Stephen Rothwell <sfr@canb.auug.org.au>,
linux-kernel@vger.kernel.org, live-patching@vger.kernel.org,
linux-next@vger.kernel.org
Subject: Re: livepatching tree for linux-next
Date: Tue, 23 Dec 2014 09:10:56 -0600 [thread overview]
Message-ID: <20141223151056.GA4789@treble.redhat.com> (raw)
In-Reply-To: <20141223094607.GA16445@infradead.org>
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:
> > Hi Stephen,
> >
> > 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:
https://git.kernel.org/cgit/linux/kernel/git/jikos/livepatching.git/commit/?h=for-next&id=13d1cf7e702596e0cd8ec62afa6bd49c431f2d0c
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.
--
Josh
next prev parent reply other threads:[~2014-12-23 15:11 UTC|newest]
Thread overview: 28+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-12-22 19:52 livepatching tree for linux-next Jiri Kosina
2014-12-23 9:46 ` Christoph Hellwig
2014-12-23 15:10 ` Josh Poimboeuf [this message]
2014-12-26 4:56 ` Stephen Rothwell
2015-01-07 22:43 ` Andrew Morton
2015-01-07 23:01 ` Jiri Kosina
2015-01-07 23:30 ` Andrew Morton
2015-01-07 23:49 ` Jiri Kosina
2015-01-07 23:57 ` Andrew Morton
2015-01-08 0:11 ` Jiri Kosina
2015-01-08 0:33 ` Andrew Morton
2015-01-08 2:22 ` Jingoo Han
2015-01-12 12:45 ` Masami Hiramatsu
2015-01-13 22:47 ` [PATCH] ftrace: don't allow IPMODIFY without proper compiler support (was Re: Re: livepatching tree for linux-next) Jiri Kosina
2015-01-14 2:12 ` Steven Rostedt
2015-01-14 8:47 ` [PATCH 1/2 v2] ftrace: don't allow IPMODIFY without proper compiler support Jiri Kosina
2015-01-14 8:48 ` [PATCH 2/2] kprobes: compile out IPMODIFY support if ftrace doesn't support it Jiri Kosina
2015-01-15 3:04 ` Masami Hiramatsu
2015-01-15 3:34 ` [PATCH 1/2 v2] ftrace: don't allow IPMODIFY without proper compiler support Masami Hiramatsu
2015-01-15 9:34 ` Jiri Kosina
2015-01-15 9:50 ` [PATCH 1/2 v3] " Jiri Kosina
2015-01-15 9:50 ` [PATCH 2/2 v3] kprobes: compile out IPMODIFY support if ftrace doesn't support it Jiri Kosina
2015-01-16 16:35 ` [PATCH 1/2 v3] ftrace: don't allow IPMODIFY without proper compiler support Steven Rostedt
2015-01-16 16:41 ` Jiri Kosina
2015-01-16 16:53 ` Steven Rostedt
2015-01-14 2:34 ` [PATCH] ftrace: don't allow IPMODIFY without proper compiler support (was Re: Re: livepatching tree for linux-next) Masami Hiramatsu
2015-01-14 8:34 ` Jiri Kosina
2015-01-09 10:03 ` livepatching tree for linux-next Jiri Kosina
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20141223151056.GA4789@treble.redhat.com \
--to=jpoimboe@redhat.com \
--cc=hch@infradead.org \
--cc=jkosina@suse.cz \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-next@vger.kernel.org \
--cc=live-patching@vger.kernel.org \
--cc=sfr@canb.auug.org.au \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).