| |
|
 |
|
 |
|
|
|
| |
|
|
xen-devel
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
|
|
|
| |
|
Home