From: Ian Campbell <ian.campbell@citrix.com>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
Cc: "xen-devel@lists.xenproject.org" <xen-devel@lists.xenproject.org>,
Euan Harris <euan.harris@citrix.com>,
Rob Hoes <Rob.Hoes@citrix.com>
Subject: Re: [PATCH RFC 1/9] libxl idl: add comments to error enum
Date: Tue, 30 Jun 2015 13:19:21 +0100 [thread overview]
Message-ID: <1435666761.21469.117.camel@citrix.com> (raw)
In-Reply-To: <21901.25249.450124.562601@mariner.uk.xensource.com>
On Fri, 2015-06-26 at 15:33 +0100, Ian Jackson wrote:
> Ian Campbell writes ("Re: [Xen-devel] [PATCH RFC 1/9] libxl idl: add comments to error enum"):
> > It would be a bit wrong to have an application specific error code in
> > the library space.
>
> Yes.
>
> > Perhaps we should declare some ranges which for specific uses. For
> > instance perhaps 0x7FFF0000..0x7FFFFFFF could be set aside for the
> > application, so xl can define itself some errors which it can use for
> > its own needs without needing to handle two separate error spaces. xl
> > could then define these codes itself.
>
> All libxl errors are negative and no libxl function returns (either (a
> nonnegative success value) or (a negative error code)).
I'm having trouble parsing the boolean logic here.
I think you are saying that every libxl function either:
Returns 0 on success and a -ve code on error
-or-
Returns positive value success or 0 on error.
But there are no functions which return a positive value on success and
a negative error code on failure.
Is that right? I think I must have misinterpreted since a) I'm not sure
that is true and b) the presence of +ve success values makes the +ve
space unavailable for error codes in the bits of applications which use
them.
> If we were just to promise that then the application has a wide space
> of numbers.
>
> > Likewise perhaps libxl internal errors should be given their own range,
> > which the application can legitimately expect never to see.
>
> This is unwise; they might escape...
True. The reason to keep them together was to make it easier to check
for them en masse at library exit points. Doesn't stop them escaping but
might help.
> > I was originally think about this in the context of the xenstore patch
> > in this series, i.e. declaring that some range is used for the existing
> > XS error codes (e.g. 0x3000xxxx is a xenstore code). I'm not sure if
> > that's a good idea or not.
>
> I have no objection to mapping existing error code spaces into libxl
> ones. But we need to do this with a bit of care. I think passing
> xenstore or hypervisor errno numbers directly to the caller will often
> be a bad idea.
Right.
Ian.
next prev parent reply other threads:[~2015-06-30 12:19 UTC|newest]
Thread overview: 33+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-06-24 13:47 [PATCH RFC 0/9] libxl error reporting Rob Hoes
2015-06-24 13:47 ` [PATCH RFC 1/9] libxl idl: add comments to error enum Rob Hoes
2015-06-24 15:06 ` Ian Jackson
2015-06-26 14:12 ` Rob Hoes
2015-06-26 14:26 ` Ian Campbell
2015-06-26 14:33 ` Ian Jackson
2015-06-30 12:19 ` Ian Campbell [this message]
2015-06-25 15:58 ` Ian Campbell
2015-06-25 16:36 ` Ian Jackson
2015-06-24 13:47 ` [PATCH RFC 2/9] libxl idl: allow implicit enum values Rob Hoes
2015-06-24 15:08 ` Ian Jackson
2015-06-25 15:59 ` Ian Campbell
2015-06-26 14:20 ` Rob Hoes
2015-06-24 13:47 ` [PATCH RFC 3/9] libxl: introduce specific xenstore error codes Rob Hoes
2015-06-24 15:10 ` Ian Jackson
2015-06-26 14:36 ` Rob Hoes
2015-06-26 14:42 ` Rob Hoes
2015-06-24 13:47 ` [PATCH RFC 4/9] libxl: use explicit error codes in libxl_ctx_alloc Rob Hoes
2015-06-24 15:18 ` Ian Jackson
2015-06-24 13:47 ` [PATCH RFC 5/9] libxl: introduce specific JSON error codes Rob Hoes
2015-06-24 15:20 ` Ian Jackson
2015-06-24 13:47 ` [PATCH RFC 6/9] libxl: introduce specific error code for libxl__wait_device_connection Rob Hoes
2015-06-24 15:30 ` Ian Jackson
2015-06-24 13:47 ` [PATCH RFC 7/9] libxl: introduce specific error codes in libxl_device_disk_add Rob Hoes
2015-06-24 15:28 ` Ian Jackson
2015-06-26 16:49 ` Rob Hoes
2015-06-24 13:47 ` [PATCH RFC 8/9] libxl: introduce specific error codes in libxl_device_cdrom_insert Rob Hoes
2015-06-24 15:26 ` Ian Jackson
2015-06-26 16:27 ` Rob Hoes
2015-06-24 13:47 ` [PATCH RFC 9/9] libxl: introduce specific error codes in libxl_device_nic_add Rob Hoes
2015-06-24 15:11 ` Ian Jackson
2015-06-26 16:36 ` Rob Hoes
2015-06-24 15:16 ` [PATCH RFC 0/9] libxl error reporting Ian Jackson
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=1435666761.21469.117.camel@citrix.com \
--to=ian.campbell@citrix.com \
--cc=Ian.Jackson@eu.citrix.com \
--cc=Rob.Hoes@citrix.com \
--cc=euan.harris@citrix.com \
--cc=xen-devel@lists.xenproject.org \
/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.