From mboxrd@z Thu Jan  1 00:00:00 1970
From: Ian Campbell <ian.campbell@citrix.com>
Subject: Re: [PATCH v3 COLOPre 16/26] tools/libx{l,
 c}: add back channel to libxc
Date: Wed, 1 Jul 2015 15:21:01 +0100
Message-ID: <1435760461.21469.290.camel@citrix.com>
References: <1435213552-10556-1-git-send-email-yanghy@cn.fujitsu.com>
	<1435213552-10556-17-git-send-email-yanghy@cn.fujitsu.com>
	<1435659052.21469.68.camel@citrix.com>	<559352B6.2010400@cn.fujitsu.com>
	<1435747338.21469.252.camel@citrix.com>	<5593C881.80600@citrix.com>
	<1435749706.21469.273.camel@citrix.com>
	<21907.55301.504151.217533@mariner.uk.xensource.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: <21907.55301.504151.217533@mariner.uk.xensource.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: Ian Jackson <Ian.Jackson@eu.citrix.com>
Cc: wei.liu2@citrix.com, wency@cn.fujitsu.com, Andrew Cooper <andrew.cooper3@citrix.com>, yunhong.jiang@intel.com, eddie.dong@intel.com, xen-devel@lists.xen.org, guijianfeng@cn.fujitsu.com, rshriram@cs.ubc.ca, Yang Hongyang <yanghy@cn.fujitsu.com>
List-Id: xen-devel@lists.xenproject.org

On Wed, 2015-07-01 at 13:07 +0100, Ian Jackson wrote:
> Ian Campbell writes ("Re: [Xen-devel] [PATCH v3 COLOPre 16/26] tools/libx{l, c}: add back channel to libxc"):
> > So to restate the question: Why does the current design deviate from the
> > design in the paper, or does the paper not say what we think it says.
> 
> To be clear, I have no problem if the design has changed since the
> paper was written.  I just want:
> 
>  * A clear high-level explanation of the actually-implemented
>    arrangements to exist somewhere
> 
>  * The commit messages, or code, to refer to that explanation
> 
> A description and explanation of the difference from some other
> somewhat different previously-published document is IMO necessary in
> this case because the primary design reference is that
> previously-published document, which does not correspond to the actual
> code.

Also in this case the implementation requires a significant new bit of
functionality (the back channel) which the previously-published design
did not, so knowing what about that design was
wrong/inadequate/impractical is useful so we can see that the new
functionality is justified.

> 
> Having a design document which disagrees with the implementation is
> dangerous because future programmers will look to the design to
> understand what is going on.
> 
> Ian.