From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Chen, Tiejun" Subject: Re: [v10][PATCH 16/16] tools: parse to enable new rdm policy parameters Date: Mon, 20 Jul 2015 21:53:47 +0800 Message-ID: <55ACFD6B.40200@intel.com> References: <1437373023-14884-1-git-send-email-tiejun.chen@intel.com> <1437373023-14884-17-git-send-email-tiejun.chen@intel.com> <21932.64262.729686.732681@mariner.uk.xensource.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; Format="flowed" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <21932.64262.729686.732681@mariner.uk.xensource.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: Ian Jackson Cc: Stefano Stabellini , Wei Liu , Ian Campbell , xen-devel@lists.xen.org List-Id: xen-devel@lists.xenproject.org > For clarity: > > I am not acking this patch, primarily because I am not happy with the > code in xlu_rdm_parse which is (a) the result of repeated > clone-and-hack and (b) consists of ad-hoc string pointer fiddling. Yes, I knew you mentioned this previously but I also remember our last deal was something as follows: ">>> Really I would prefer that this parsing was done with a miniature flex >>> parser, rather than ad-hoc pointer arithmetic and use of strtok. >> >> Sorry, could you show this explicitly? > > Something like what was done for disk devices. See libxlu_disk_l.l > for an example. In this case your code would be a lot less > complicated than what you see there. > > After the codefreeze I would probably have some time to write it for Sounds yourself would do this so currently I just keep the original, right? Thanks Tiejun > you. (I think that would be valuable because libxlu_disk_l.l is a > very complicated example, and I want be able to point future > submitters at something simpler.) > > Ian." Then I didn't receive any response again so I thought yourself made this promise. Thanks Tiejun > > If I had been able to review this patch earlier in the release cycle I > would be explictly nacking this patch. It is true that maybe someone > will have some time to clean this up later; but in practice it often > turns out that they don't - which is why we usually try not to accept > patches on the basis of promises to do further cleanup. > > However, I am late to this party. I first made this complaint in > response to v7 on the 9th of July. Under the circumstances I am going > to stand aside and neither ack nor nack this patch. > > The rules then say that the patch may be committed given that it has > Wei's ack as a tools maintainer. > > Ian. >