Re: [xSplice Minutes from IRC chat Oct 26 2015]

[Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>]

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.