From: Gerd Hoffmann <kraxel@suse.de>
To: Keir Fraser <Keir.Fraser@cl.cam.ac.uk>
Cc: Ian Pratt <m+Ian.Pratt@cl.cam.ac.uk>,
Anthony Liguori <aliguori@us.ibm.com>,
xen-devel@lists.xensource.com,
"Daniel P. Berrange" <berrange@redhat.com>
Subject: Re: Re: Error reporting capabilities for libxc
Date: Tue, 24 Oct 2006 12:26:17 +0200 [thread overview]
Message-ID: <453DEA49.1030602@suse.de> (raw)
In-Reply-To: <C1639666.33BA%Keir.Fraser@cl.cam.ac.uk>
Keir Fraser wrote:
> On 24/10/06 08:47, "Gerd Hoffmann" <kraxel@suse.de> 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 <kraxel@suse.de>
http://www.suse.de/~kraxel/julika-dora.jpeg
next prev parent reply other threads:[~2006-10-24 10:26 UTC|newest]
Thread overview: 25+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-09-26 12:58 Error reporting capabilities for libxc Ian Pratt
2006-09-26 13:20 ` Daniel P. Berrange
2006-10-23 18:00 ` Daniel P. Berrange
2006-10-23 19:17 ` Anthony Liguori
2006-10-23 19:27 ` Daniel P. Berrange
2006-10-23 20:04 ` Anthony Liguori
2006-10-23 20:08 ` Daniel P. Berrange
2006-10-23 20:54 ` Ian Pratt
2006-10-23 20:57 ` Daniel P. Berrange
2006-10-23 21:10 ` Ian Pratt
2006-10-23 21:14 ` Anthony Liguori
2006-10-23 21:28 ` Daniel P. Berrange
2006-10-23 21:38 ` Anthony Liguori
2006-10-23 21:47 ` John Levon
2006-10-24 9:15 ` Daniel Veillard
2006-10-23 21:48 ` Daniel P. Berrange
2006-10-24 7:47 ` Gerd Hoffmann
2006-10-24 9:07 ` Keir Fraser
2006-10-24 10:26 ` Gerd Hoffmann [this message]
2006-10-23 21:21 ` Daniel P. Berrange
2006-10-23 22:15 ` Ian Pratt
2006-10-23 23:05 ` Daniel P. Berrange
2006-10-23 20:40 ` John Levon
2006-10-23 21:04 ` John Levon
2006-10-23 21:09 ` Daniel P. Berrange
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=453DEA49.1030602@suse.de \
--to=kraxel@suse.de \
--cc=Keir.Fraser@cl.cam.ac.uk \
--cc=aliguori@us.ibm.com \
--cc=berrange@redhat.com \
--cc=m+Ian.Pratt@cl.cam.ac.uk \
--cc=xen-devel@lists.xensource.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.