From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1N8bKR-0004hG-AU for qemu-devel@nongnu.org; Thu, 12 Nov 2009 10:11:19 -0500 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1N8bKM-0004f4-0B for qemu-devel@nongnu.org; Thu, 12 Nov 2009 10:11:18 -0500 Received: from [199.232.76.173] (port=48251 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1N8bKL-0004em-Cn for qemu-devel@nongnu.org; Thu, 12 Nov 2009 10:11:13 -0500 Received: from mx1.redhat.com ([209.132.183.28]:1160) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1N8bKK-0001JU-On for qemu-devel@nongnu.org; Thu, 12 Nov 2009 10:11:13 -0500 Date: Thu, 12 Nov 2009 13:10:51 -0200 From: Luiz Capitulino Subject: Re: [Qemu-devel] [RFC 0/8]: QError v2 Message-ID: <20091112131051.13d2fda7@doriath> In-Reply-To: <4AFC1F33.4060405@linux.vnet.ibm.com> References: <1257365047-25895-1-git-send-email-lcapitulino@redhat.com> <4AFB2A9E.9050309@codemonkey.ws> <20091112114108.4cca3405@doriath> <4AFC1F33.4060405@linux.vnet.ibm.com> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Anthony Liguori Cc: Anthony Liguori , qemu-devel@nongnu.org, kraxel@redhat.com, pbonzini@redhat.com, hollisb@linux.vnet.ibm.com On Thu, 12 Nov 2009 08:44:03 -0600 Anthony Liguori wrote: > 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). This can happen with errors that carry specific info which are different among subsystems, eg. USB device info vs. PCI device info. We could have 'USBDeviceAlreadyOpen', but then I think the class attribute will lose generality. > >> 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. Right, although there's a long road until we stabilize. > >> 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 > > QERR_DEVICE_ALREADY_OPEN? > > > > We can either change the index on the table to be just the class code or > find something more clever. I'm working on this and trying to find something. > >> 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. I've found other problems with it, let's pretend I didn't mention it. :)