From mboxrd@z Thu Jan 1 00:00:00 1970 From: George Dunlap Subject: Re: [PATCH] libxl: Make an internal function explicitly check existence of expected paths Date: Tue, 27 Nov 2012 11:50:15 +0000 Message-ID: <50B4A8F7.5050702@eu.citrix.com> References: <85552b648b3cabebd4f5.1353686197@elijah> <1354016648.17985.13.camel@zakaz.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: <1354016648.17985.13.camel@zakaz.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 Campbell Cc: "xen-devel@lists.xensource.com" List-Id: xen-devel@lists.xenproject.org On 27/11/12 11:44, Ian Campbell wrote: > On Fri, 2012-11-23 at 15:56 +0000, George Dunlap wrote: >> + LIBXL__LOG(ctx, LIBXL__LOG_ERROR, >> + "Internal error: Missing xenstore node %s/removable", be_path); > > One or two of these new log lines are > 80 columns. You might find that > using the shorthand LOG*() macros helps with this. Oops -- I'll fix that up. > > Personally I don't think the "Internal error" tag is necessary either, > but maybe a new return code ERROR_INTERNAL might make sense? or even an > assert() if this is really a "libxl failed to maintain internal > consistency" ? The idea behind the "Internal" tag is to tell users, "Unless you've been manually messing around with xenstore removing nodes, this is definitely not your fault." I guess normally an ASSERT communicates that pretty well, but I guess I'm used to ASSERTs that disappear when DEBUG is turned off. :-) Is that not the case for libxl? -George