* Re: [xSplice Minutes from IRC chat Oct 26 2015]
[not found] <20151026152355.GE5618@l.oracle.com>
@ 2015-10-27 14:05 ` Konrad Rzeszutek Wilk
0 siblings, 0 replies; only message in thread
From: Konrad Rzeszutek Wilk @ 2015-10-27 14:05 UTC (permalink / raw)
To: xen-devel
Cc: elena.ufimtseva, hanweidong, jbeulich, john.liuqiming,
paul.voccio, daniel.kiper, major.hayden, liuyingdong, aliguori,
xen-devel, lars.kurth, steven.wilson, ian.campbell, rboos,
peter.huangpeng, msw, xiantao.zxt, rick.harris, boris.ostrovsky,
jinsong.liu, amesserl, mpohlack, ross.lagerwall, fanhenglong,
andrew.cooper3
Argh, had the wrong To.
Resending again.
On Mon, Oct 26, 2015 at 11:23:55AM -0400, Konrad Rzeszutek Wilk wrote:
> Hey,
>
> Attendees:
>
> Ross
> Andrew
> Martin
> Konrad
>
> Minutes:
> - We moved the meeting to Tuesday (same time) due to conflict issues.
> However we were still able to discuss a fair amount.
>
> - Decided that our goal is to have 'v1' of the code to be in Xen 4.7.
> Hence need to slim down the scope so that folks can review the code
> comfortably.
>
> - v1 will be experimental and the ABI is fluid.
>
> - v1 will encompass:
> - In Xen code base, Konrad's xsplice.v1.2 codebase which has
> the hypervisor, XSM, and toolstack changes.
>
> - In Xen code base, Ross's changes in Xen xSplice code for
> module loading (aka ELF payload loading).
>
> - The patching will be just simple function patching (code).
> This will slim down the design document.
>
> - The Ross's kpatching code (userspace tools to generate diff between
> binaries) will be a in seperate git tree and not integrated in.
>
> [Note: that we are actually here. That is all the code for this exists
> in Ross's two git trees.]
>
> - Xen code base will utilize the kpatching code (so pull in external
> git tree) to generate an ELF payload for a very simple patch
> (altering xen_extra_version).
>
> - Remove bugs :-)
>
>
> - v2:
> - Utilize 'disambiguate symbol names' patches.
> - Figure out what we want for v3.
>
> - v3 and further versions:
> - Figure out where Ross's kpatching code should go. Should it go
> in kpatching git tree or stay in Xen code base.
> - Provide an mechanism to do automated testing (OSSTest perhaps?)
> - Use Andrew's super-mapping work as they will leave tons of extra
> physical space to .text, .data, and .rodata which can be used.
> - Figure out what we want for v4, and so on.
>
> That was it.
^ permalink raw reply [flat|nested] only message in thread