From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Daniel P. Berrange" Subject: Re: Error reporting capabilities for libxc Date: Tue, 26 Sep 2006 14:18:22 +0100 Message-ID: <20060926131822.GA8885@redhat.com> References: <1159271107.7649.10.camel@sisko.scot.redhat.com> Reply-To: "Daniel P. Berrange" Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Return-path: Content-Disposition: inline In-Reply-To: List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com To: Keir Fraser Cc: "xen-devel@lists.xensource.com" List-Id: xen-devel@lists.xenproject.org On Tue, Sep 26, 2006 at 01:28:37PM +0100, Keir Fraser wrote: > > > > On 26/9/06 12:45, "Stephen C. Tweedie" wrote: > > >> So, I've prototyped a simple error reporting mechanism for libxc. The idea > >> is we first define an enum for the broad classes of errors which can occur. > > ... > > > >> Any way, the upshot of all this work: > >> # xm create error > >> Using config file "error". > >> Error: [2, 'Kernel ELF architecture 3 does not match Xen architecture 62'] > > > > IMHO this is sorely needed. Any comments from XenSource people? > > I'd agree something like this is necessary in the 3.0.4 timeframe. I'll let > one of the guys more acquainted with xend comment in detail. There's also > the question of how this will integrate with the proposed 'XenAPI'. I don't anticipate any problems integrating with XenAPI - we've previously discussed the need to enumerate a set of error codes for XenAPI operations and the need to also pass back descriptive string of the problem so I should think its a good fit 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 -=|