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. > > 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. -- Joe
