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

[Anthony Liguori <aliguori@us.ibm.com>]

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);
>
> 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.

>
> 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.

-- 
Regards,

Anthony Liguori