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

Re: [Xen-devel] Re: [PATCH] [XEN-API] Not raising an API error in VTPM d

To: Ewan Mellor <ewan@xxxxxxxxxxxxx>
Subject: Re: [Xen-devel] Re: [PATCH] [XEN-API] Not raising an API error in VTPM destroy method
From: Stefan Berger <stefanb@xxxxxxxxxx>
Date: Thu, 8 Feb 2007 14:08:09 -0500
Cc: xen-devel <xen-devel@xxxxxxxxxxxxxxxxxxx>, xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
Delivery-date: Thu, 08 Feb 2007 11:07:51 -0800
Envelope-to: www-data@xxxxxxxxxxxxxxxxxx
In-reply-to: <20070208190014.GG2043@xxxxxxxxxxxxxxxxxxxxxx>
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>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx

xen-devel-bounces@xxxxxxxxxxxxxxxxxxx wrote on 02/08/2007 02:00:14 PM:

> On Thu, Feb 08, 2007 at 01:25:23PM -0500, Stefan Berger wrote:
>
> > xen-devel-bounces@xxxxxxxxxxxxxxxxxxx wrote on 02/08/2007 10:53:24 AM:
> >
> > > On Wed, Feb 07, 2007 at 06:37:19PM -0500, Stefan Berger wrote:
> > >
> > > > Don't return an API error if vTPM cannot be destroyed due to a running
> > > > VM, but a value indicating failure instead. Adapt python code, libxen
> > > > and documentation.
> > > >
> > > > Signed-off-by: Stefan Berger <stefanb@xxxxxxxxxx>
> > >
> > > We have a separate error-returning mechanism -- you should be using that
> > > rather than returning an error code.  Take a look at the end of
> > > xenapi-datamodel.tex; the error code definitions are there.  In
> > XendAPI.py,
> > > you have xen_api_error available, which will marshall an error code and
> > > arguments, and in xen/xm/messages there is a translation database for
> > those
> > > error messages.
> >
> > Thanks for pointing this out. I looked at the xenapi-datamodel.tex, of
> > course, but I mostly find information related to the errors in 1.3.1 and
> > towards the end of the document there's the debug class, but I don't think
> > you are referring to that one.
>
> No, I mean the version that's in xen-unstable.  There's section 2.24 on error
> handling in there.
>
> > The reason why I am actually trying to get rid of the 'return
> > xen_api_error(...)' statement is that if I am using the C client library
> > ,libxen, the session->ok parameter changes to 'false' if this error comes
> > back when for example trying to delete a vTPM from a running VM. I have
> > tried to make the session usable again by doing 'session->ok = true'  so I
> > don't have to establish yet another session -- not sure whether that is an
> > allowed usage model of the session, though. Although this session works
> > for further transactions the program fails at the point when the session
> > is cleaned up with glibc complaining about bad memory. So the easiest way
> > to circumvent this is to have the API return an error code for failure of
> > the operation using xen_api_success().
>
> That might be the easiest way, but it's certainly the wrong one!
>
> This has been discussed a little on the xen-api list before, though I agree
> that the documentation needs to be updated.  Setting session->ok back to true
> when you've handled the error is fine.  The intention is to allow you to chain
> together short groups of calls, and then check for errors at appropriate
> points.  (If you prefer, you can check for errors after every single call,
> that's fine too.)
>
> If you're getting a segfault or a glibc-detected error, then that's clearly a
> bug.  Could you post your code so that I can try it?


I'll try to put something in your test case that triggers this error.

   Stefan


>
> Ewan.
>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@xxxxxxxxxxxxxxxxxxx
> http://lists.xensource.com/xen-devel
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel