From mboxrd@z Thu Jan  1 00:00:00 1970
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
Subject: Re: [v7][PATCH 16/16] tools: parse to enable new rdm
 policy parameters
Date: Mon, 13 Jul 2015 18:08:52 +0100
Message-ID: <21923.61604.203298.653166@mariner.uk.xensource.com>
References: <1436420047-25356-1-git-send-email-tiejun.chen@intel.com>
	<1436420047-25356-17-git-send-email-tiejun.chen@intel.com>
	<21918.48191.157583.452591@mariner.uk.xensource.com>
	<559F60AB.2060402@intel.com>
	<21919.40225.618413.570220@mariner.uk.xensource.com>
	<55A38583.9080204@intel.com>	<1436780431.7019.54.camel@citrix.com>
	<55A38B0F.1050608@intel.com>	<1436782646.7019.76.camel@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: <1436782646.7019.76.camel@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: Ian Campbell <ian.campbell@citrix.com>
Cc: "Chen, Tiejun" <tiejun.chen@intel.com>, xen-devel@lists.xen.org, Wei Liu <wei.liu2@citrix.com>, Stefano Stabellini <stefano.stabellini@eu.citrix.com>
List-Id: xen-devel@lists.xenproject.org

Ian Campbell writes ("Re: [Xen-devel] [v7][PATCH 16/16] tools: parse to enable new rdm policy parameters"):
> On Mon, 2015-07-13 at 17:55 +0800, Chen, Tiejun wrote:
> > So I can do this as you're expecting now, but seems our change would 
> > make the code style very inconsistent inside this function.

You're right, it would, but I think that is what is called for.

> I think one could make an argument that the exception described in the
> first section of tools/libxl/CODING_STYLE applies here for the
> whitespace issues, but not for the long lines I think.

The wording of the exception is that:

  If it is not feasible to conform fully to the style while patching old
  code, without doing substantial style reengineering first, we may
  accept patches which contain nonconformant elements, provided that
  they don't make the coding style problem worse overall.

  In this case, the new code should conform to the prevailing style in
  the area being touched.

In this case it is indeed feasible to conform fully to the new
whitespace style for these added lines.  It leaves the code in this
function in a mixture of styles, but that is not "infeasible".  It is
merely undesriable, but so is adding more code in the wrong style.

The sentence about new code conforming to the prevailing style applies
only "in this case", ie, only if "it is not feasible ... to conform to
the new style".

Ian.