All of lore.kernel.org
 help / color / mirror / Atom feed
From: George Dunlap <george.dunlap@eu.citrix.com>
To: Ian Campbell <Ian.Campbell@citrix.com>
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [PATCH] libxl: Make an internal function explicitly check existence of expected paths
Date: Tue, 27 Nov 2012 11:50:15 +0000	[thread overview]
Message-ID: <50B4A8F7.5050702@eu.citrix.com> (raw)
In-Reply-To: <1354016648.17985.13.camel@zakaz.uk.xensource.com>

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

  reply	other threads:[~2012-11-27 11:50 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-11-23 15:56 [PATCH] libxl: Make an internal function explicitly check existence of expected paths George Dunlap
2012-11-27 11:44 ` Ian Campbell
2012-11-27 11:50   ` George Dunlap [this message]
2012-11-27 11:55     ` Ian Campbell
  -- strict thread matches above, loose matches on Subject: below --
2012-11-30 17:13 George Dunlap
2012-12-04 14:35 ` Ian Campbell
2012-12-05 14:34   ` George Dunlap
2012-12-05 18:28 George Dunlap
2012-12-05 18:29 ` George Dunlap

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=50B4A8F7.5050702@eu.citrix.com \
    --to=george.dunlap@eu.citrix.com \
    --cc=Ian.Campbell@citrix.com \
    --cc=xen-devel@lists.xensource.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.