From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Daniel P. Berrange" Subject: Re: Error reporting capabilities for libxc Date: Mon, 23 Oct 2006 20:27:53 +0100 Message-ID: <20061023192753.GG25795@redhat.com> References: <3AAA99889D105740BE010EB6D5A5A3B202A3B1@paddington.ad.cl.cam.ac.uk> <20061023180017.GE25795@redhat.com> <453D1554.8000202@us.ibm.com> Reply-To: "Daniel P. Berrange" Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Return-path: Content-Disposition: inline In-Reply-To: <453D1554.8000202@us.ibm.com> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com To: Anthony Liguori Cc: xen-devel@lists.xensource.com List-Id: xen-devel@lists.xenproject.org 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" 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 -=|