[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-devel] [PATCH RFC 1/9] libxl idl: add comments to error enum



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.


_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.