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 -- To unsubscribe from this list: send the line "unsubscribe live-patching" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
