[Qemu-devel] Re: [RFC 0/7] QError v1

[Luiz Capitulino]

 (Added Daniel Berrange to the CC list)

On Fri, 30 Oct 2009 08:09:02 -0500
Anthony Liguori <address@hidden> wrote:

> Gerd Hoffmann wrote:
> > On 10/30/09 13:28, Luiz Capitulino wrote:
> >>>> -        qemu_error("Device \"%s\" not found.  Try -device '?' for 
> >>>> a list.\n",
> >>>> -                   driver);
> >>>> +        qemu_error_structed(QERR_DEV_NFOUND, "{ 'name': %s }", 
> >>>> driver);
> >>>
> >>> why not store the "{ 'name': %s }" in the qerror_table?  I guess you
> >>> plan to have different fields in some cases?
> >>
> >>   The main reason is to have syntax checking, we can declare it in a
> >> macro though, in case of generic errors which are going to be used in
> >> other places.
> >
> > I still feel the error reporting is too complex.  IMHO there should be 
> > no need to edit two places for error reporting, which means I'd go the 
> > opposite direction:  Zap qerror_table[], then have:
> >
> > qemu_error_structed(QERR_DEV_NFOUND, "device %{name}s not found",
> >                     "{ 'name': %s }", driver);

 I'm ok with this.

> > Also I think the error codes should be more generic, so you don't need 
> > a new one for each and every error.  Ideally we'll have a reasonable 
> > and stable set of error codes after the initial conversion, so you 
> > don't have to touch the management apps just to add new codes as qemu 
> > envolves.  The error code must help the management app to decide how 
> > to deal with the error, but it shouldn't carry details not needed for 
> > that.
> 
> Okay, let's get more clever then and do:
> 
> #define QERR_DEV_NFOUND "{ 'code': 404, 'name': %s}"
> 
> So we can do:
> 
> qemu_error_structured(QERR_DEV_NFOUND, driver);
> 
> Such that we still get printf style parameter checking.

 Seems ok to me, but to make it harder to reuse existing error
codes we'd have to:

1. Make mandatory the use of a macro in the qemu_error_structed()
   call
2. All macros would have to be defined in qerror.h

 Btw, why are you calling it qemu_error_structured()? It's a long
name, let's call it qemu_erro_structed() or any better name.. I
thought about qemu_error_throw()..

> > Picking the balloon errors (other patch in this thread):  You have 
> > *two* error codes for ballooning not being available.  I think a 
> > generic "service not available" error code would work for both (and 
> > for other error cases too) and would be good enougth.  The management 
> > app will figure it can't balloon down the VM.  It will not know the 
> > reason from the error code, but does it have to?  I doubt it will 
> > react in a different way.  And for manual trouble-shooting the text 
> > message which carries more information gets logged.
> 
> I think the trouble is Luiz is trying to preserve today's error 
> messages.  Honestly, if we need to break those, I don't mind so much 
> because I really doubt anyone is depending on the exact text of the 
> error messages.
> 
> I agree that a bit more generic error messages wouldn't be a bad thing.

 I think we're back to the discussion regarding what information
an error should contain.

 Daniel seems to want as most info as possible:

http://lists.gnu.org/archive/html/qemu-devel/2009-10/msg01640.html

 In case we put only the error code and error data on the wire,
I think error codes should be *unique* and not generic. This way
clients are able to determine the exact error cause.

 If we go with generic errors, then we would have to send the
user string along. This introduces the problem of localization
and can be a bit redundant, as the call above would be emitted
like:

{ "error": { "code": 404,
             "desc": "driver foobar not found",
             "data": { "name": foobar" } } }