From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1N3r1X-0001s7-Ou for qemu-devel@nongnu.org; Fri, 30 Oct 2009 08:56:11 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1N3r1T-0001lN-0X for qemu-devel@nongnu.org; Fri, 30 Oct 2009 08:56:11 -0400 Received: from [199.232.76.173] (port=33099 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1N3r1S-0001lC-Mg for qemu-devel@nongnu.org; Fri, 30 Oct 2009 08:56:06 -0400 Received: from mx1.redhat.com ([209.132.183.28]:38797) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1N3r1S-0006xk-0D for qemu-devel@nongnu.org; Fri, 30 Oct 2009 08:56:06 -0400 Message-ID: <4AEAE261.5030908@redhat.com> Date: Fri, 30 Oct 2009 13:56:01 +0100 From: Gerd Hoffmann MIME-Version: 1.0 References: <1256841750-15228-1-git-send-email-lcapitulino@redhat.com> <4AEA133A.8010906@redhat.com> <20091030102809.1c520282@doriath> In-Reply-To: <20091030102809.1c520282@doriath> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [Qemu-devel] Re: [RFC 0/7] QError v1 List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Luiz Capitulino Cc: Paolo Bonzini , aliguori@us.ibm.com, qemu-devel@nongnu.org, hollisb@us.ibm.com On 10/30/09 13:28, Luiz Capitulino wrote: >>> - qemu_error("Device \"%s\" not found. Try -device '?' for a list.\n", >>> - driver); >>> + qemu_error_structed(QERR_DEV_NFOUND, "{ 'name': %s }", driver); >> >> why not store the "{ 'name': %s }" in the qerror_table? I guess you >> plan to have different fields in some cases? > > The main reason is to have syntax checking, we can declare it in a > macro though, in case of generic errors which are going to be used in > other places. I still feel the error reporting is too complex. IMHO there should be no need to edit two places for error reporting, which means I'd go the opposite direction: Zap qerror_table[], then have: qemu_error_structed(QERR_DEV_NFOUND, "device %{name}s not found", "{ 'name': %s }", driver); Also I think the error codes should be more generic, so you don't need a new one for each and every error. Ideally we'll have a reasonable and stable set of error codes after the initial conversion, so you don't have to touch the management apps just to add new codes as qemu envolves. The error code must help the management app to decide how to deal with the error, but it shouldn't carry details not needed for that. Picking the balloon errors (other patch in this thread): You have *two* error codes for ballooning not being available. I think a generic "service not available" error code would work for both (and for other error cases too) and would be good enougth. The management app will figure it can't balloon down the VM. It will not know the reason from the error code, but does it have to? I doubt it will react in a different way. And for manual trouble-shooting the text message which carries more information gets logged. cheers, Gerd