[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-devel] Re: Error reporting capabilities for libxc



On 24/10/06 08:47, "Gerd Hoffmann" <kraxel@xxxxxxx> wrote:

>> 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.
> 
> That doesn't allow a descriptive text message, which is often quite
> useful to figure what went wrong in detail.  error codes such as errno
> == EINVAL are not very helpful for trouble shooting ...
> 
> 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). xc_{get,set}_errtext()
(or whatever it is called) could co-exist with this, so I am personally in
favour of the patch, at least as a starting point for further work. It
directly tackles our biggest current err-handling problem, which is stupidly
throwing away useful diagnostic info (or writing it to log files where it
gets hidden in with piles of other crap).

I guess using __thread is the best of a bad set of choices, by the way.
It'll limit us to gcc-3.3.x and later, which is fine. And we'll want to
build 32-bit with -mno-tls-direct-seg-refs. We can add that to CFLAGS for
all tools. I was wondering about explicitly stating that libxc is no
thread-safe for any given 'xc handle', but actually that is just storing up
bigger trouble.

 -- Keir



_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.