Re: [Xen-devel] [PATCH v4 22/32] libxl_qmp: Handle messages from QEMU

[Roger Pau Monné <roger.pau@xxxxxxxxxx>]

On Fri, Aug 03, 2018 at 06:25:00PM +0100, Anthony PERARD wrote:
> On Thu, Aug 02, 2018 at 01:17:37PM +0200, Roger Pau Monné wrote:
> > On Fri, Jul 27, 2018 at 03:06:04PM +0100, Anthony PERARD wrote:
> > > diff --git a/tools/libxl/libxl_types.idl b/tools/libxl/libxl_types.idl
> > > index 4a385801ba..e104fea941 100644
> > > --- a/tools/libxl/libxl_types.idl
> > > +++ b/tools/libxl/libxl_types.idl
> > > @@ -69,6 +69,10 @@ libxl_error = Enumeration("error", [
> > >      (-23, "NOTFOUND"),
> > >      (-24, "DOMAIN_DESTROYED"), # Target domain ceased to exist during op
> > >      (-25, "FEATURE_REMOVED"), # For functionality that has been removed
> > > +    (-26, "QMP_GENERIC_ERROR"), # unspecified qmp error
> > > +    (-27, "QMP_COMMAND_NOT_FOUND"), # the requested command has not been 
> > > found
> > > +    (-28, "QMP_DEVICE_NOT_ACTIVE"), # a device has failed to be become 
> > > active
> > > +    (-29, "QMP_DEVICE_NOT_FOUND"), # the requested device has not been 
> > > found
> > 
> > Do we really need such granularity for QMP errors? Isn't it enough to
> > have a single ERROR_QMP or similar?
> 
> No I don't think so. QMP_COMMAND_NOT_FOUND can be useful when a qmp
> command is removed (there is already one that is deprecated and we use).
> 
> The last two could be useful to user of libxl as they could provide
> better error messages. xl don't care because whatever error message is
> attach to the error, it will be printed.

I wonder if this set of errors will change very often, at the end of
day it's not controlled by ourselves but QEMU, and then how much
chasing will libxl have to do in order to keep up with new types of
QMP errors.

IMO I don't see a lot of value in returning specific QMP error codes
from libxl, and I would even consider whether it's worth to have
something like ERROR_QMP, because I don't think there's much the
caller can do in case of QMP failure. It's an internal libxl QMP
error, and it's not like the caller is going to start it's own QMP
connection in order to speak with QEMU directly in order to solve
whatever QMP issue it got from libxl.

Roger.

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxxx
https://lists.xenproject.org/mailman/listinfo/xen-devel