Re: [Qemu-devel] [PATCH 6/9] QError: Add qdev not found error

[Hollis Blanchard <hollisb@us.ibm.com>]

On Thu, 2009-10-15 at 16:08 -0300, Luiz Capitulino wrote:
> On Thu, 15 Oct 2009 11:13:53 -0700
> Hollis Blanchard <hollisb@us.ibm.com> wrote:
> 
> > On Thu, 2009-10-15 at 14:52 -0300, Luiz Capitulino wrote:
> > > 
> > > > You could easily have
> > > >       qemu_error(code, "device not found");
> > > 
> > >  This doesn't solve the problems I mentioned above, besides I don't
> > > see why you need to specify both, the error code and the description,
> > > they describe the same thing.
> > 
> > This is how FTP and other protocols work, for example.
> 
>  I meant in the qemu_error() call, we will certainly emit them both
> in the protocol.
> 
> > You supplied a perfect example:
> > 	qemu_error(404, "husb: host usb device %d.%d is already open\n",
> >                       bus_num, addr);
> > 
> > In this case, an interactive client could only display the "pretty"
> > text.
> > 
> > A machine client would interpret the code as Markus described in a
> > previous mail (temporary server error, permanent server error, etc). In
> > case of a permanent server error, the client could *also* pass through
> > the pretty text to display to the user.
> 
>  Ok, so this design is really different from what I had in mind.

I'm starting to see that. :)

>  In your design error codes are more like errors classes, right? So,
> using your example, 404 could have the meaning 'already open, temporary',
> this way it can be used with USB, PCI or even for files.
> 
>  How do you plan to emit it on the wire? Like this:
> 
> { "error": { "code": 404,
>              "desc": "husb: host usb device 0.12 is already open" } }
> 
>  In case I'm right, there are two problems with it:
> 
> 1. It's hard to retrieve the variable information
> 2. Maybe minor, but I see too much information for a protocol

I'm really confused by your objections. This is simply HTTP-style
"Status Code" and "Reason
Phrase" (http://tools.ietf.org/html/rfc2616#section-6.1.1) in JSON form.

1. The client receiving the response clearly has a JSON interpreter, so
how is it hard to retrieve anything?
2. Have you ever used software that said "Failed." without explanation?
Unless you're suggesting that all clients would build in their own
code->description tables (I hope to god you're not :), we must transmit
the description in the protocol.

> > Aside from that, we should certainly be able to change the pretty text,
> > for example, to provide additional clarification to the user. The
> > machine-interpreted code, on the other hand, wouldn't change.
> 
>  How do you plan to do it in the design you're proposing? If you
> use the text from qemu_error() to build the user and protocol
> outputs, then you can't change it.

Today it looks like this:
        C: open host USB device foo
        S: error 404, host USB device foo is already open

Tomorrow it could look like this:
        C: open host USB device foo
        S: error 404, host USB device foo is already open by PID 27

As described in HTTP's section 6.1.1:
   The Status-Code is intended
   for use by automata and the Reason-Phrase is intended for the human
   user. The client is not required to examine or display the Reason-
   Phrase.

Since the automata only interprets the status code, nothing breaks, and
the user benefits from more information.

-- 
Hollis Blanchard
IBM Linux Technology Center