On Mon, Oct 23, 2006 at 04:38:54PM -0500, Anthony Liguori wrote:
> 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.
Where is it utterly inaccessible for any applications talking to XenD.
> 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?
You don't neccessarily show that level of detail to the user, but it is
important to propagate it all the way back to the tools talking to libxc
or Xend. xm, or libvirt, or virt-manager, or any other tool talking to
XenD should have access to this kind of debugging info. If I'm doing
off-box management of hosts & a domain create operation fails, I don't
want to have to login to the box in question to get this information
out of the xend logs, when xend could quite easily have passed it all
back over the wire in the first place.
> If a user passes an invalid kernel line in the config, I think an
> appropriate error would be "Kernel <filename> 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.
It really depends on the end user in question. If the information is
available, an API should pass it back to the applicationxs to decide what
level of detail is appropriate to present. We shouldn't encode the
error reporting policy in the API itself, because it has no idea of the
needs of the caller.
BTW, when I say 'user' i mean caller of the (Xend) APIs (ie applications),
rather than human operators.
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 -=|
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|
Home