[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
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |