WARNING - OLD ARCHIVES

This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
   
 
 
Xen 
 
Home Products Support Community News
 
   
 

xen-devel

[Xen-devel] [PATCH] Add error reporting to libxc library

To: xen-devel@xxxxxxxxxxxxxxxxxxx
Subject: [Xen-devel] [PATCH] Add error reporting to libxc library
From: "Daniel P. Berrange" <berrange@xxxxxxxxxx>
Date: Tue, 5 Dec 2006 02:25:24 +0000
Delivery-date: Mon, 04 Dec 2006 18:25:27 -0800
Envelope-to: www-data@xxxxxxxxxxxxxxxxxx
List-help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-id: Xen developer discussion <xen-devel.lists.xensource.com>
List-post: <mailto:xen-devel@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
Reply-to: "Daniel P. Berrange" <berrange@xxxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
User-agent: Mutt/1.4.1i
Attached to this mail is an update of my previous patch to add an error
reporting API to the libxc library.  The patch is against xen-devel on
changeset 12722.

Previous discussions were:

 Original post:
  http://lists.xensource.com/archives/html/xen-devel/2006-09/msg00702.html

 2nd posting:
  http://lists.xensource.com/archives/html/xen-devel/2006-10/msg01041.html


This 3rd version of the patch has the following characteristics:

 - An 'xc_error' struct is used to pass around error details. Currently
   contains two members 'code' an enumeration of error types, and
   'message' a free text description of the specific problem. 

 - The xc_get_last_error() method returns a const pointer to the internal
   instance of this struct manged by libxc. By returning a const pointer we 
   can add extra members to the end of the struct at any time without 
   worrying about ABI of callers. This will let us provide more fine grained
   info if needed in the future.

 - The xc_error instance is statically defined inside libxc and marked
   __thread. This ensures that errors are recorded per-thread, and that
   when dealing with errors we never need to call malloc - all storage
   needed is statically allocated.

 - The xc_clear_last_error() method resets any currently recorded error
   details

 - The xc_error_code_to_desc() method converts the integer error code
   into a generic user facing messsage. eg "Invalid kernel". Together
   with the 'message' field from xc_error, this provides the user 
   visible feedback. eg "Invalid kernel: Non PAE-kernel on PAE host."

 - A callback can be registered with xc_set_error_handler to receive
   notification whenever an error is recorded, rather than querying
   for error details after the fact with xc_get_last_error

 - If built with -DDEBUG set, a default error handler will be registered
   which calls fprintf(stderr), thus maintaining current behaviour of
   logging errors to stderr during developer builds.

 - The python binding for libxc is updated to use xc_get_last_error
   to pull out error details whenever appropriate, instead of returning
   info based on 'errno'

 - The xc_set_error method is private to libxc internals, and is used
   for setting error details

 - The ERROR and PERROR macros have been updated to call xc_set_error
   automatically specifying XC_INTERNAL_ERROR as the error code. This
   gives a generic error report for all current failure points

 - Some uses of the ERROR macro have been replaced with explicit
   calls to xc_set_error to enable finer grained error reporting. In
   particular the code dealing with invalid kernel types uses this
   to report about PAE/architecture/wordsize mismatches

This should address the recommendations / suggestions from the previous
round of feedback on this patch.

The patch has been tested by calling xm create against a varietry of
config files defining invalid kernels of various kinds. It has also
been tested with libvirt talking to xend. In both cases the error
messages were propagated all the way back up the stack.

There is only one place where I need to do further work. The suspend
& restore APIs in Xend invoke external helper programs rather than
calling libxc directly. This means that error details are essentially
lost. Since there is already code in XenD which scans STDERR from these
programs I will investigate adapting this to extract actual error
mesages from these helpers.

Since I've not been keeping up with development on XenAPI I'm not clear
on what (if any) extra code is needed to get errors integrated with
this new control API. Hopefully it should be little-to-no work, but 
I could do with someone who knows XenAPI details validating this.

   Signed-off-by: Daniel P. Berrange <berrange@xxxxxxxxxx>

Regards,
Dan.
-- 
|=- Red Hat, Engineering, Emerging Technologies, Boston.  +1 978 392 2496 -=|
|=-           Perl modules: http://search.cpan.org/~danberr/              -=|
|=-               Projects: http://freshmeat.net/~danielpb/               -=|
|=-  GnuPG: 7D3B9505   F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505  -=| 

Attachment: xen-3.0.4-libxc-errors.patch
Description: Text document

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
<Prev in Thread] Current Thread [Next in Thread>
  • [Xen-devel] [PATCH] Add error reporting to libxc library, Daniel P. Berrange <=