qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Luiz Capitulino
Subject: Re: [Qemu-devel] [PATCH 6/9] QError: Add qdev not found error
Date: Thu, 15 Oct 2009 16:08:39 -0300

On Thu, 15 Oct 2009 11:13:53 -0700
Hollis Blanchard <address@hidden> 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.

 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

 In the design I'm proposing, *each* different error will get a code,
no problem to have classes of errors though, but the point is that
error text doesn't go on the call to qemu_error().

 The above example can be emitted like this:

{ "error": { "code": 12
             "desc": "device already open",
             "data": { "bus": 0, "address": 12 } } }

 Note that this also can be reused by any bus, as the "data" information
is built at error time and can contain anything.

> >  Also, they must not change after the protocol gets into production,
> > having them defined in the same place will help.
> 
> This seems really unnecessary and too much abstraction.

 I don't agree it's unnecessary, but I agree it has too much abstraction
and making the errors harder to report will make developers tentative
in not reporting errors at all (Markus argument).

 Maybe we need clearer requirements?

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

 In current QError this is possible.




reply via email to

[Prev in Thread] Current Thread [Next in Thread]