WARNING - OLD ARCHIVES

This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
   
 
 
Xen 
 
Home Products Support Community News
 
   
 

xen-devel

[Xen-devel] Re: Error reporting capabilities for libxc

To: Anthony Liguori <aliguori@xxxxxxxxxx>
Subject: [Xen-devel] Re: Error reporting capabilities for libxc
From: "Daniel P. Berrange" <berrange@xxxxxxxxxx>
Date: Mon, 23 Oct 2006 20:27:53 +0100
Cc: xen-devel@xxxxxxxxxxxxxxxxxxx
Delivery-date: Mon, 23 Oct 2006 12:28:12 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxx
In-reply-to: <453D1554.8000202@xxxxxxxxxx>
List-help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-id: Xen developer discussion <xen-devel.lists.xensource.com>
List-post: <mailto:xen-devel@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
References: <3AAA99889D105740BE010EB6D5A5A3B202A3B1@xxxxxxxxxxxxxxxxxxxxxxxxxx> <20061023180017.GE25795@xxxxxxxxxx> <453D1554.8000202@xxxxxxxxxx>
Reply-to: "Daniel P. Berrange" <berrange@xxxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
User-agent: Mutt/1.4.1i
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