lkml.org 
[lkml]   [2017]   [Oct]   [20]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH 0/8] livepatch: klp-convert tool
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

\
 
 \ /
  Last update: 2017-10-22 17:35    [W:0.239 / U:0.872 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site