From mboxrd@z Thu Jan 1 00:00:00 1970 From: Ian Campbell Subject: Re: [PATCH] xl: Change output from xl -N create to be more useful Date: Tue, 30 Jun 2015 12:22:47 +0100 Message-ID: <1435663367.21469.110.camel@citrix.com> References: <1435328955-19744-1-git-send-email-ian.jackson@eu.citrix.com> <20150626151031.GL6265@zion.uk.xensource.com> <21901.28718.398582.229226@mariner.uk.xensource.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <21901.28718.398582.229226@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: Euan Harris , xen-devel@lists.xensource.com, Wei Liu List-Id: xen-devel@lists.xenproject.org On Fri, 2015-06-26 at 16:30 +0100, Ian Jackson wrote: > Wei Liu writes ("Re: [PATCH] xl: Change output from xl -N create to be more useful"): > > On Fri, Jun 26, 2015 at 03:29:15PM +0100, Ian Jackson wrote: > ... > > > Note that this change is NOT BACKWARDS COMPATIBLE. But it would only > > > adversely affects anyone who uses `xl -N create' and then saves and > > > processes the JSON. (The output from xl list et al is not changed; it > > > normally needs the domid.) Such a user should probably have already > > > have complained about the infelicitous output. If they haven't it > > > would be simple enough for them to bookend the output so as to provide > > > compatible output. > > > > > > If this backward compatibility problem is considered a blocker for > > > this patch, then I will respin, with one of the following two > > > workarounds: > > > - A new option to force sane output > > > - Generate output which contains the domain config twice, > > > once directly in the main struct, and a copy in "config" > > > > I don't think keeping a broken interface for the sake of backward > > compatibility is worth it. > > The interface isn't unuseable. You just have to use jq(1) or > something to transform the output. > > AFAIAA we have no in-tree consumers of libxl json domain configs and > further I'm not aware of any out-of-tree consumers apart from the one > I just introduced into the xs-ring3 ao abort test suite. > > But, thanks for the favourable opinion :-). I think we should just risk the change and if anyone notices and cares we could consider retrofitting OUTPUT_FORMAT_JSON_XEN45 to xl. I think it's unlikely anyone will notice. Ian.