Re: [Xen-devel] [PATCH RFC 0/9] libxl error reporting

[Ian Jackson <Ian.Jackson@xxxxxxxxxxxxx>]

Rob Hoes writes ("[PATCH RFC 0/9] libxl error reporting"):
> 
> Following the proposal from Euan Harris to improve libxl's error
> reporting [1], I have written a first couple of patches that I would
> like some feedback on.  The focus of these patches is on improving
> the errors that can be raised by the device_add functions and some
> related ones.
> 
> Does the approach look acceptable?

Your plan looks like 1. document existing stuff 2. go around fixing
things.  That seems good to me.

> Do the error codes make sense?

I will reply in detail.

> Did I miss any error conditions?

This is too hard to answer I think.

> One thing I wasn't sure about is what happens if
> libxl__wait_device_connection times out.

The devstate and hence the underlying libxl__ev_timeout will time out
generating rc == ERROR_TIMEDOUT.

I think if we are to do this properly we might want
libxl__ev_timeout's setup to take an rc value to generate for
timeouts.  We could have:

  ERROR_TIMEDOUT_GUEST
  ERROR_TIMEDOUT_BACKEND
  ERROR_TIMEDOUT_HOTPLUG

at the very least.

> Also, I realise that these patches essentially break backward
> compatibility, and I have not done the "#define LIBXL_HAVE" stuff
> yet. Do people consider this necessary, and if so, at what
> granularity (e.g. one LIBXL_HAVE for all new error codes in a
> release)?

We should probably have, at the end of the series,
LIBXL_HAVE_<something>, for the whole batch.

In general I don't think we need to care very much about backward
compatibility for API callers, because making application decisions
based on the existing vague error codes is basically impossible.
(Barring a few exceptions.)

Ian.

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