From mboxrd@z Thu Jan 1 00:00:00 1970 From: Anthony Liguori Subject: Re: Re: Error reporting capabilities for libxc Date: Mon, 23 Oct 2006 16:38:54 -0500 Message-ID: <453D366E.5020201@us.ibm.com> References: <453D1554.8000202@us.ibm.com> <20061023192753.GG25795@redhat.com> <3AAA99889D105740BE010EB6D5A5A3B205073B@paddington.ad.cl.cam.ac.uk> <20061023205730.GI25795@redhat.com> <3AAA99889D105740BE010EB6D5A5A3B205073C@paddington.ad.cl.cam.ac.uk> <453D30D3.6090007@us.ibm.com> <20061023212802.GL25795@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <20061023212802.GL25795@redhat.com> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com To: "Daniel P. Berrange" Cc: Ian Pratt , xen-devel@lists.xensource.com List-Id: xen-devel@lists.xenproject.org Daniel P. Berrange wrote: > On Mon, Oct 23, 2006 at 04:14:59PM -0500, Anthony Liguori wrote: > >> Ian Pratt wrote: >> >>> Would we be better off returning an error code and a set of parameters, >>> requiring a call-back into the library to get the string? >>> >>> It's worth thinking about future language localisation here too. >>> >>> >> I know it's a bigger patch, but the Right Thing to do here is to just >> propagate an error code through the libxc functions. >> >> The whole xc_{get,set}_error() is a cludge. Threading wouldn't be a >> problem if we returned proper error codes. >> > > This would be an insufficient level of detail compared to my patch. An error > code alone can tell you there was an invalid kernel, or even particular tests > which failed. It can *not* tell you that when the architecture mis-matched, > the expected arch was 'i386' and the actual arch was 'x86_64'. Hence why > I provided both an error code & a detailed message. > > Notice in the following there are two strings - 'Invalid kernel' is the > string associated with the error code 'XC_INVALID_KERNEL'. This is the > generic static mapping. The second string though is dynamically generated > according to the specific metadata which was incorrect - this is the > invaluable user facing information which cuts down on debugging pain. > stdout from libxenctrl gets redirected to the Xend logs. You could write this sort of info to the logs. I don't know of many users that will be able to make sense out of the following lines. How many users know what an "ELF architecture" is that wouldn't be capable of looking in log file? If a user passes an invalid kernel line in the config, I think an appropriate error would be "Kernel is not a valid Xen kernel." That's pretty clear and understandable. This message is totally reproducible in xm with just an XC_INVALID_KERNEL error code. Regards, Anthony Liguori > [root@dhcp-4-245 ~]# xm create crash > Using config file "/etc/xen/crash". > Error: [2, 'Invalid kernel', "Kernel ELF architecture '3' does not match Xen architecture '62' (x86_64)"] > [root@dhcp-4-245 ~]# xm create crash > Using config file "/etc/xen/crash". > Error: [2, 'Invalid kernel', "Kernel ELF type '3' does not match Xen type '2'"] > [root@dhcp-4-245 ~]# xm create crash > Using config file "/etc/xen/crash". > Error: [2, 'Invalid kernel', 'Not a valid ELF or raw kernel image'] > > Dan. >