[Top][All Lists]

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

Re: [Qemu-devel] [RFC 0/8]: QError v2

From: Anthony Liguori
Subject: Re: [Qemu-devel] [RFC 0/8]: QError v2
Date: Thu, 12 Nov 2009 08:44:03 -0600
User-agent: Thunderbird (X11/20090825)

Luiz Capitulino wrote:

#define QERR_DEVICE_ALREADY_OPEN "{'class': 'DeviceAlreadyOpen', 'data' : {'bus_num': %d, 'addr': %d}"

qemu_error_new(QERR_DEVICE_ALREADY_OPEN, bus_num, addr);

 What about DeviceAlreadyOpen errors with a different argument list?

Why would you have this? That would seem like a problem to me. I think the errors need to be very well structured (just like everything else in QMP).

That gives us a nice simple interface with full error checking on the parameters.

 I've said this is not so simple because people writing those macros
would find out that the 'class' or 'data' _keys_ are missing or incorrect
only at run-time, when the error is triggered.

Sure but introducing new types of errors is not the common case. Using existing errors is the common case.

For human readable strings, I'd suggest making a table somewhere else that looked like:

QErrorStringTable qerror_descriptions[] = {
{ QERR_DEVICE_ALREADY_OPEN, "This device at %(bus_num)d.%(addr)d is already open." },

 How do you suggest we lookup the table? Doing a strcmp() on

We can either change the index on the table to be just the class code or find something more clever.

There are a number of advantages to an approach like this. The table can be reused by both in the server and by a client.

 My suggestions on both problems makes me willing go back to my initial
series, which had a table indexed by an error number.

I don't understand why.


Anthony Liguori

reply via email to

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