From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753668AbdJSQUF (ORCPT ); Thu, 19 Oct 2017 12:20:05 -0400 Received: from mx1.redhat.com ([209.132.183.28]:54148 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752482AbdJSQUE (ORCPT ); Thu, 19 Oct 2017 12:20:04 -0400 DMARC-Filter: OpenDMARC Filter v1.3.2 mx1.redhat.com E9D5681138 Authentication-Results: ext-mx03.extmail.prod.ext.phx2.redhat.com; dmarc=none (p=none dis=none) header.from=redhat.com Authentication-Results: ext-mx03.extmail.prod.ext.phx2.redhat.com; spf=fail smtp.mailfrom=jpoimboe@redhat.com Date: Thu, 19 Oct 2017 11:20:01 -0500 From: Josh Poimboeuf To: Miroslav Benes Cc: Joao Moreira , live-patching@vger.kernel.org, linux-kernel@vger.kernel.org, mmarek@suse.cz, pmladek@suse.com, jikos@suse.cz, nstange@suse.de, jroedel@suse.de, matz@suse.de, khlebnikov@yandex-team.ru, jeyu@kernel.org Subject: Re: [PATCH 0/8] livepatch: klp-convert tool Message-ID: <20171019162001.4y3lb3eqsucop6x4@treble> References: <20170830180025.3s5tscqf5isqwg5n@treble> <20171011024615.y55lwbgpgo6b5dll@treble> <14124e34-04f7-950e-72fb-64f13e62f57e@suse.de> <20171019130146.uxjuhgn2t3yavgz2@treble> <20171019140338.pngwewyzllaw2wu5@treble> <20171019151522.5ih3egvzr3wm3h7r@treble> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.6.0.1 (2016-04-01) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.27]); Thu, 19 Oct 2017 16:20:04 +0000 (UTC) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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