From mboxrd@z Thu Jan 1 00:00:00 1970 From: Gerd Hoffmann Subject: Re: Re: Error reporting capabilities for libxc Date: Tue, 24 Oct 2006 12:26:17 +0200 Message-ID: <453DEA49.1030602@suse.de> References: Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Return-path: 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: Ian Pratt , Anthony Liguori , xen-devel@lists.xensource.com, "Daniel P. Berrange" List-Id: xen-devel@lists.xenproject.org Keir Fraser wrote: > On 24/10/06 08:47, "Gerd Hoffmann" wrote: > >> What number space we are talking about btw? errno? something else? > > I think a separate numbering space, where each err number would have some > number of auxiliary arguments is being suggested, probably with an > xc_{get,set}_errnum() interface (since the 'errnum' would not be a simple > scalar so would be a bit of a pain to pass around). I somehow feel this is a bit overdesigned. I've just walked through my domain builder rewrite, trying to assign useful error codes. After all there are not that many different cases: (1) internal errors (all sorts of sanity checks which normally never ever fail except when coding new bugs ;) ). (2) out of memory. (3) reading some file failed (kernel / initrd / hvmloader / whatelse). (4) invalid kernel image (broken elf headers, truncated file, ...). (5) incompatible kernel image (pae vs. nonpae, ppc kernel on x86, ...). (6) some invalid parameter (such as asking for a feature not supported by hypervisor or guest kernel, ...) And the is only one where a fixed set of parameters specifying in detail what went wrong somehow makes sense: for #3 this would be the filename and maybe the reason (EPERM, ENOENT, ...). For the other ones IMHO only free text makes sense as detailed description ... cheers, Gerd -- Gerd Hoffmann http://www.suse.de/~kraxel/julika-dora.jpeg