Re: [Qemu-devel] [PATCH 00/10]: QError v4

[Luiz Capitulino]

On Mon, 23 Nov 2009 14:50:05 +0100
Alexander Graf <address@hidden> wrote:

> 
> Am 23.11.2009 um 14:34 schrieb Luiz Capitulino <address@hidden>:
> 
> > On Mon, 23 Nov 2009 07:11:53 -0600
> > Anthony Liguori <address@hidden> wrote:
> >
> >> Luiz Capitulino wrote:
> >>> On Sun, 22 Nov 2009 10:08:16 -0600
> >>> Anthony Liguori <address@hidden> wrote:
> >>>
> >>>
> >>>> I'm certainly willing to consider alternative ways to do qmp_error 
> >>>> () but
> >>>> taking a free form string is not an option in my mind. It goes  
> >>>> against
> >>>> the fundamentals of what we're trying to build with QMP.
> >>>>
> >>>
> >>> Agreed.
> >>>
> >>>
> >>>> So if you're opposed to structured error data, just having
> >>>> qmp_error(error_code) is a reasonable alternative. I don't think  
> >>>> it's
> >>>> the right thing to do, but I think it's still within the spirit  
> >>>> of the
> >>>> goals of QMP.
> >>>>
> >>>
> >>> You mean, we would have calls like:
> >>>
> >>> qemu_error_new(error_code, 'device '%s' not found', name);
> >>>
> >>
> >> Except drop the 'device %s not found' bit.
> >
> > We would need a table to have the strings for the user protocol
> > then. Not having the table is a key point in Markus's argument,
> > I guess.
> 
> We would need that for internationalization anyways, right?
> 
> Though I don't dislike the idea of passing a plain default syntax over  
> the wire as a bonus / fallback. Especially for cases where the ui is  
> older than qemu.
> 
> So why not have the table inside qemu do a lookup and send that as  
> default format in addition to the error code (that should usually be  
> used to find out the format)?

 The current proposal does have a table, the argument against it is
that we're making error reporting complex, as developers will have to
edit more than one place to report errors.