From: Wei Liu Subject: Re: [PATCH 8/9] xl: make error reporting of cpupool subcommands consistent Date: Wed, 11 Mar 2015 15:23:02 +0000 Message-ID: <20150311152302.GC1643@zion.uk.xensource.com> References: <20150306170758.7269.53821.stgit@Solace.station> <20150306172159.7269.37267.stgit@Solace.station> <20150309110122.GK18491@zion.uk.xensource.com> <1426085551.21353.254.camel@citrix.com> <20150311150444.GA1643@zion.uk.xensource.com> <1426086800.21405.8.camel@citrix.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: Content-Disposition: inline In-Reply-To: <1426086800.21405.8.camel@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: Dario Faggioli Cc: "JGross@suse.com" , Wei Liu , Ian Campbell , "xen-devel@lists.xen.org" , Stefano Stabellini , Ian Jackson List-Id: xen-devel@lists.xenproject.org On Wed, Mar 11, 2015 at 03:13:33PM +0000, Dario Faggioli wrote: > On Wed, 2015-03-11 at 15:04 +0000, Wei Liu wrote: > > On Wed, Mar 11, 2015 at 02:52:31PM +0000, Ian Campbell wrote: > > > > I think having more consistent exist codes from xl would be nice, but I > > > don't think the libxl error codes are the ones to use, since they don't > > > really map semantically onto what I would expect a CLI tool to fail with > > > (I'm not sure what I would expect though, something a bit higher level > > > on a command specific basis probably). > > > > > > > I agree that libxl error codes are not the ones to use. > > > > Since we haven't explicitly defined any return value in xl manpage, I > > think we should use EXIT_SUCCESS and EXIT_FAILURE per exit(3). > > > I like the idea. > > > They are > > more appropriate then 0 and 1. > > > Indeed. However, as far as this patch is concerned, what should I do? > > a) drop it, and leave libxl error code in place, until we convert > everything to EXIT_SUCCESS/FAILURE > b) keep it, we'll convert the 0/1 to EXIT_SUCCESS/FAILURE in later > patch(es) > c) turn libxl error codes into EXIT_SUCCESS/FAILURE at least for this > functions, since I'm touching them, the rest will come with later > patch(es) > ? > > My opinion, I don't like c), so I'd go for either a) or b), with a > slight preference for b). > I think b) is good. > Let me know... > > Regards, > Dario