[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20190615204736.coc2gbgffahkirnz@treble>
Date: Sat, 15 Jun 2019 15:47:36 -0500
From: Josh Poimboeuf <jpoimboe@...hat.com>
To: Petr Mladek <pmladek@...e.com>
Cc: Jiri Kosina <jikos@...nel.org>, Miroslav Benes <mbenes@...e.cz>,
Joe Lawrence <joe.lawrence@...hat.com>,
Kamalesh Babulal <kamalesh@...ux.vnet.ibm.com>,
Nicolai Stange <nstange@...e.de>,
live-patching@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [RFC 0/5] livepatch: new API to track system state changes
On Tue, Jun 11, 2019 at 03:56:22PM +0200, Petr Mladek wrote:
> Hi,
>
> this is another piece in the puzzle that helps to maintain more
> livepatches.
>
> Especially pre/post (un)patch callbacks might change a system state.
> Any newly installed livepatch has to somehow deal with system state
> modifications done be already installed livepatches.
>
> This patchset provides, hopefully, a simple and generic API that
> helps to keep and pass information between the livepatches.
> It is also usable to prevent loading incompatible livepatches.
>
> There was also a related idea to add a sticky flag. It should be
> easy to add it later. It would perfectly fit into the new struct
> klp_state.
>
> Petr Mladek (5):
> livepatch: Keep replaced patches until post_patch callback is called
> livepatch: Basic API to track system state changes
> livepatch: Allow to distinguish different version of system state
> changes
> livepatch: Documentation of the new API for tracking system state
> changes
> livepatch: Selftests of the API for tracking system state changes
I confess I missed most of the previous discussion, but from a first
read-through this seems reasonable, and the code looks simple and
self-contained.
--
Josh
Powered by blists - more mailing lists