On Wed, Aug 29, 2018 at 3:41 AM, Joe Lawrence <joe.lawrence@xxxxxxxxxx> wrote: > On Mon, Aug 27, 2018 at 10:33:51AM +0200, Petr Mladek wrote: >> On Fri 2018-08-24 13:21:19, Miroslav Benes wrote: >> > On Tue, 21 Aug 2018, Jiri Kosina wrote: >> > >> > > On Thu, 2 Aug 2018, Jiri Kosina wrote: >> > > >> > > > as in previous years (and as discussed with quite a few of you in person), >> > > > I've just submitted LPC2018 miniconf proposal for live patching. >> > > >> > > For those of you who are planning to attend, please send either me or Josh >> > > (and CC the list) the topic you'd like to get discussed, and your >> > > preliminary statement / confirmation whether you'd be making best effort >> > > to participate. >> > >> > First, yes, I'd like to participate. >> >> I would like to participate as well. >> > > I would be interested in participating, too. I would be interested in participating, too. > >> > As for the topics. Hopefully, the atomic replace and basic selftests will >> > have been merged by then, so that is one topic less. >> >> Let's see ;-) >> > > I don't mind talking about the selftests if there is any interest in > what was already posted (what and how it tests), or if anyone has ideas > on extending them in some way. > >> > 1. Architecture support. >> > >> > ... >> > >> > s390x has ftrace with regs support and klp_arch_set_pc() implemented. >> > objtool and reliable stack traces need to be discussed. Reportedly >> > some of SUSE's customers have been asking about s390x support >> > recently. >> > >> > So, it'd nice to talk about objtool and archs' peculiarities. Especially >> > if arch maintainers attend the event. > > I'm interested in s390x, but am nowhere near an architecture expert. I > posted a few weeks back [1] regarding the consistency model and my > tinkering with s390x, but got no bites from the linux-s390 mailing list > folks. It would be great if an arch maintainer could stop by for the > event. > > [1] https://www.spinics.net/lists/live-patching/msg04465.html > >> > 3. Userspace tool for live patches creation ("better kpatch-build"). >> > Nothing new here I'm afraid, but Joao may have some input. Also Nicolai >> > has been working on the first steps to generate live patches from the >> > source code approach. It'd interesting to hear about that and discuss its >> > viability. >> >> AFAIK, Nicolai tried to create an API to transfer state and data between >> various versions of livepatches. The primary goal is to keep the >> callbacks maintainable. They might need to create, update, take over, >> or destroy some data structures according to the actual state >> of already installed livepatches. >> >> We might discuss it if there is a wider interest into such an API. > > I would find this interesting to see with examples. I'm assuming > data/state might also include shadow variables, but perhaps they aren't > special enough to warrant any kind of special API consideration. I would like to do a presentation about elivepatch[1]. (a wrapper for kpatch-build that is trying to make livepatch flexible, distributed and recently interested in automation) [1] https://wiki.gentoo.org/wiki/Elivepatch -- Thanks, Alice Ferrazzi Gentoo Kernel Project Leader Gentoo Foundation Vice-Secretary Gentoo Google Summer of Code Administrator Mail: Alice Ferrazzi <alice.ferrazzi@xxxxxxxxx> PGP: 2E4E 0856 461C 0585 1336 F496 5621 A6B2 8638 781A
