From mboxrd@z Thu Jan 1 00:00:00 1970 From: David Vrabel Subject: Re: [PATCH v6 0/13] Migration Stream v2 Date: Tue, 8 Jul 2014 11:50:05 +0100 Message-ID: <53BBCCDD.7010405@citrix.com> References: <1404754682-28379-1-git-send-email-andrew.cooper3@citrix.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <1404754682-28379-1-git-send-email-andrew.cooper3@citrix.com> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: Andrew Cooper , Xen-devel Cc: Keir Fraser , Ian Campbell , Tim Deegan , Ian Jackson , Frediano Ziglio , David Vrabel , Jan Beulich List-Id: xen-devel@lists.xenproject.org On 07/07/14 18:37, Andrew Cooper wrote: > > The next area of work is the libxl integration, which will seek to undo the > current layering violations. It will involve introducing a new libxl framing > format (which will happen to look curiously similar to the libxc framing > format), as well as providing legacy compatibility using the legacy conversion > scripts so migrations from older libxl/libxc toolstacks will continue to work. I think the xl/libxl work is orthogonal to this libxc work. If the libxl maintainers are keen on addressing similar problems with the libxl stream protocol then perhaps they could volunteer? It seems somewhat unfair to require people fixing a related area in libxc to also do this work. The two problem areas between libxl and libxc are: 1. qemu save record processed by the libxc restore code -- this is an internal implementation detail that has no impact on the save record format. 2. The TOOLSTACK record. I think it would be acceptable to leave this for now and deprecate it once it becomes unnecessary. It's only a minor problem. David