[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [Xen-devel] Re: Error reporting capabilities for libxc
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@xxxxxxxxxx> 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 -=| _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxxxxxxxx http://lists.xensource.com/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |