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