On Fri, Aug 03, 2018 at 06:25:00PM +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.
If the users of libxl aren't likely to care about the exact error
messages, we don't need to expose these at all. They are more suitable
to be put under libxl_internal_types.idl.
And then you translate the internal error numbers into external ones
where appropriate.
Wei.
>
> Thanks,
>
> --
> Anthony PERARD
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
