xen-devel-bounces@lists.xensource.com 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@lists.xensource.com 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@us.ibm.com>
> > >
> > > 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?
> 
> Ewan.
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel