From mboxrd@z Thu Jan  1 00:00:00 1970
From: Frediano Ziglio <frediano.ziglio@citrix.com>
Subject: Re: [PATCH 0/6] [VERY RFC] Migration Stream v2
Date: Tue, 15 Apr 2014 09:30:57 +0100
Message-ID: <1397550657.10048.4.camel@hamster.uk.xensource.com>
References: <1397068104-23714-1-git-send-email-andrew.cooper3@citrix.com>
	<1397126549.9862.116.camel@kazak.uk.xensource.com>
	<53467EA9.1090305@citrix.com>
	<CAFLBxZZCoD1GHGOiDxMXK1=+v30FGKtsZOv8iykhrBf57Y6d+A@mail.gmail.com>
	<534C24BE.4070201@citrix.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Return-path: <xen-devel-bounces@lists.xen.org>
In-Reply-To: <534C24BE.4070201@citrix.com>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org
To: David Vrabel <david.vrabel@citrix.com>
Cc: Keir Fraser <keir@xen.org>, Ian Campbell <Ian.Campbell@citrix.com>, George Dunlap <George.Dunlap@eu.citrix.com>, Andrew Cooper <andrew.cooper3@citrix.com>, Ian Jackson <Ian.Jackson@eu.citrix.com>, Tim Deegan <tim@xen.org>, Jan Beulich <JBeulich@suse.com>, Xen-devel <xen-devel@lists.xen.org>
List-Id: xen-devel@lists.xenproject.org

On Mon, 2014-04-14 at 19:11 +0100, David Vrabel wrote:
> On 14/04/14 18:49, George Dunlap wrote:
> > On Thu, Apr 10, 2014 at 12:21 PM, Andrew Cooper
> > <andrew.cooper3@citrix.com> wrote:
> >> On 10/04/14 11:42, Ian Campbell wrote:
> >>> On Wed, 2014-04-09 at 19:28 +0100, Andrew Cooper wrote:
> >>>> Some design decisions have been take very deliberately (e.g. splitting the
> >>>> logic for PV and hvm migration) while others have been more along the lines of
> >>>> "I think its a sensible thing to do given a lack of any evidence/opinion to
> >>>> the contrary".
> >>> Is there some indication of which is which?
> >>
> >> Not really, given the clean rewrite, and also that it is only partially
> >> complete.
> >>
> >>>
> >>> Should we check in the desigh/spec which was previously posted as part
> >>> of this?
> >>
> >> I knew I forgot something...
> >>
> >> http://xenbits.xen.org/people/andrewcoop/domain-save-format-E.pdf
> > 
> > 
> > What did you imagine might constitute an "Optional" record?
> 
> This was something Ian Jackson asked for and it seems like a useful
> capabilitity to have for future use.  Not sure what it might be used for
> yet.
> 
> David

Upper layers can stick stuff like machine descriptions (ie: "Web server
for selling") or other more technical (original host name/ip, specific
modifications of host like the "User agent" stuff in http, preferred
migration encapsulation).

The definition of optional is you can discard it and machine will work
the same.

Frediano