[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20171019162001.4y3lb3eqsucop6x4@treble>
Date: Thu, 19 Oct 2017 11:20:01 -0500
From: Josh Poimboeuf <jpoimboe@...hat.com>
To: Miroslav Benes <mbenes@...e.cz>
Cc: Joao Moreira <jmoreira@...e.de>, live-patching@...r.kernel.org,
linux-kernel@...r.kernel.org, mmarek@...e.cz, pmladek@...e.com,
jikos@...e.cz, nstange@...e.de, jroedel@...e.de, matz@...e.de,
khlebnikov@...dex-team.ru, jeyu@...nel.org
Subject: Re: [PATCH 0/8] livepatch: klp-convert tool
On Thu, Oct 19, 2017 at 06:00:54PM +0200, Miroslav Benes wrote:
> On Thu, 19 Oct 2017, Josh Poimboeuf wrote:
> > My main objection to merging klp-convert in its current state is that
> > it's not useful by itself. In fact, it's actively dangerous if people
> > assume that because it's in-tree, it's the definitive way to safely
> > create patches.
> >
> > I have a similar worry about the livepatch-sample module. It's also
> > actively dangerous. Its only decent justification for being in-tree,
> > IMO, is that we at least need some type of in-tree user of the klp
> > interfaces.
>
> Well, you could use this reasoning even for kernel livepatching codebase
> itself. It is hard to use it right, but it is there and thus dangerous.
Indeed, and this is exactly why we've been working on the kpatch author
guide:
https://github.com/dynup/kpatch/blob/master/doc/patch-author-guide.md
It's currently kpatch-specific, but it mostly applies to livepatch as
well. It needs to be "ported" to livepatch and moved upstream.
But with klp-convert, there's no such documentation, because there's no
safe way to use it without other supplementary tooling which doesn't
exist.
> > klp-convert is a vast improvement to the livepatch-sample module, but I
> > view that as a bad thing because it makes it a lot easier to do
> > something stupid ;-)
> >
> > If it were part of a complete solution, with some supporting tooling
> > and/or documentation which prevent the user from making dumb mistakes,
> > then I think it would make sense to merge it.
>
> Right, so this is where our views differ a bit. I'd like to get to the
> finish line (whatever that means) slowly but steady and not to wait for
> the ultimate solution if it can be implemented step by step.
An iterative approach makes a lot of sense. But if the intermediate
steps aren't useful, does it make sense for them to be in mainline?
Can't we do development in another tree?
> I think it is time for others to express their opinions. We should talk
> about it next week at OSS.
Yes, maybe over a pilsner or two...
--
Josh
Powered by blists - more mailing lists