Re: Error reporting capabilities for libxc

["Daniel P. Berrange" <berrange@redhat.com>]

On Mon, Oct 23, 2006 at 02:17:40PM -0500, Anthony Liguori wrote:
> Daniel P. Berrange wrote:
> >On Tue, Sep 26, 2006 at 01:58:11PM +0100, Ian Pratt wrote:
> >>>On 26/9/06 12:45, "Stephen C. Tweedie" <sct@redhat.com> wrote:
> >>>
> >>>>>So, I've prototyped a simple error reporting mechanism for 
> >>>libxc. The 
> >>>>>idea is we first define an enum for the broad classes of 
> >>>errors which can occur.
> >>>>...
> >>>>
> >>>>>Any way, the upshot of all this work:
> >>>>>  # xm create error
> >>>>>  Using config file "error".
> >>>>>  Error: [2, 'Kernel ELF architecture 3 does not match Xen 
> >>>>>architecture 62']
> >>>>IMHO this is sorely needed.  Any comments from XenSource people?
> >>>I'd agree something like this is necessary in the 3.0.4 
> >>>timeframe. I'll let one of the guys more acquainted with xend 
> >>>comment in detail. There's also the question of how this will 
> >>>integrate with the proposed 'XenAPI'.
> >>Yep, definitely needs to happen. However, I think we should at least
> >>discuss alternative potentially less clunky implementation methods.
> >>Perhaps we should use a thread local errno and error string variables?
> >
> >Attached is an update to the original patch which annotates the static
> >variables with __thread so that they are setup per-thread. It also adds
> >more informative error reporting for bad kernels.
> 
> What versions of GCC have you tested this with?

I'm doing this on FC6 - the __thread annotation is the same approach
used in libc for the per-thread errno variable, hence why I chose it
try it initially. The version are:

  glibc-2.5-3
  gcc-4.1.1-30

> I've found in the past that __thread can have problems when using shared 
> libraries (the exact instance was a Python binding).

I've not explicitly tested this integrating with the python bindings
and ensuring the correct per-thread operation.

> >The only issue is that __thread is a GCC specific extension, so I'm not
> >sure this will work for the Solaris folks ?
> >
> >  http://gcc.gnu.org/onlinedocs/gcc/Thread_002dLocal.html
> >
> >The other option is to use the POSIX APIs  pthread_getspecific & 
> >pthread_setspecific. It'll make the code alot more cumbersome, but
> >would certainly be portable. I'm certainly willing to do this though
> >if need be...

One further issue I've thought of is that the __thread annotation does
not provide any way to do cleanup when a thread exists. Fine if the
per-thread variable is a simple scalar, but not so good if its a char *
since I think it'll leak memory. So I think I may have no choice by to
re-write with pthread_getspecific(), since that allows registration
of a cleanup function to free memory.

Regards,
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  -=|