From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752652AbdJTIvp (ORCPT ); Fri, 20 Oct 2017 04:51:45 -0400 Received: from mx2.suse.de ([195.135.220.15]:49623 "EHLO mx2.suse.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752356AbdJTIvn (ORCPT ); Fri, 20 Oct 2017 04:51:43 -0400 Date: Fri, 20 Oct 2017 10:51:40 +0200 (CEST) From: Miroslav Benes To: Josh Poimboeuf 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 In-Reply-To: <20171019162001.4y3lb3eqsucop6x4@treble> Message-ID: References: <20170830180025.3s5tscqf5isqwg5n@treble> <20171011024615.y55lwbgpgo6b5dll@treble> <14124e34-04f7-950e-72fb-64f13e62f57e@suse.de> <20171019130146.uxjuhgn2t3yavgz2@treble> <20171019140338.pngwewyzllaw2wu5@treble> <20171019151522.5ih3egvzr3wm3h7r@treble> <20171019162001.4y3lb3eqsucop6x4@treble> User-Agent: Alpine 2.21 (LSU 202 2017-01-01) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, 19 Oct 2017, Josh Poimboeuf wrote: > 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. Great, I'll read it. > 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. True. I don't know if I mentioned it before. There is -fdump-ipa-clones now in GCC for dumping every clone operation GCC does. https://github.com/marxin/kgraft-analysis-tool processes the dump and extracts useful information for a symbol. > > > 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? Right, that's of course an option too. > > 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... Sure :) Miroslav