From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1MyXid-0007Nh-Vx for qemu-devel@nongnu.org; Thu, 15 Oct 2009 17:18:44 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1MyXiZ-0007Lv-Lk for qemu-devel@nongnu.org; Thu, 15 Oct 2009 17:18:43 -0400 Received: from [199.232.76.173] (port=43030 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1MyXiZ-0007Lq-7l for qemu-devel@nongnu.org; Thu, 15 Oct 2009 17:18:39 -0400 Received: from e39.co.us.ibm.com ([32.97.110.160]:57333) by monty-python.gnu.org with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1MyXiY-0005aN-Mt for qemu-devel@nongnu.org; Thu, 15 Oct 2009 17:18:39 -0400 Received: from d03relay04.boulder.ibm.com (d03relay04.boulder.ibm.com [9.17.195.106]) by e39.co.us.ibm.com (8.14.3/8.13.1) with ESMTP id n9FLCjp1031617 for ; Thu, 15 Oct 2009 15:12:45 -0600 Received: from d03av03.boulder.ibm.com (d03av03.boulder.ibm.com [9.17.195.169]) by d03relay04.boulder.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id n9FLIWmu227268 for ; Thu, 15 Oct 2009 15:18:32 -0600 Received: from d03av03.boulder.ibm.com (loopback [127.0.0.1]) by d03av03.boulder.ibm.com (8.12.11.20060308/8.13.3) with ESMTP id n9FLIWHk001705 for ; Thu, 15 Oct 2009 15:18:32 -0600 Subject: Re: [Qemu-devel] [PATCH 6/9] QError: Add qdev not found error From: Hollis Blanchard In-Reply-To: <4AD78CCD.6030006@us.ibm.com> References: <1255453026-18637-1-git-send-email-lcapitulino@redhat.com> <1255453026-18637-7-git-send-email-lcapitulino@redhat.com> <1255561330.29192.2.camel@slab.beaverton.ibm.com> <20091015103405.591e2f3b@doriath> <1255626960.29192.7.camel@slab.beaverton.ibm.com> <20091015145208.1d871f09@doriath> <1255630433.29192.16.camel@slab.beaverton.ibm.com> <20091015160839.7dbef5bf@doriath> <1255637617.29192.59.camel@slab.beaverton.ibm.com> <4AD78CCD.6030006@us.ibm.com> Content-Type: text/plain Date: Thu, 15 Oct 2009 14:18:31 -0700 Message-Id: <1255641511.29192.68.camel@slab.beaverton.ibm.com> Mime-Version: 1.0 Content-Transfer-Encoding: 7bit List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Anthony Liguori Cc: kraxel@redhat.com, qemu-devel@nongnu.org, Luiz Capitulino On Thu, 2009-10-15 at 15:57 -0500, Anthony Liguori wrote: > >>> 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 > > > > What's tough about this sort of error handling is that it's not > conducive to localization. It's not unusual for the server to have a > different locale than the client so you really need the client to be > able to translate error messages into meaningful messages in the client > locale. It's hard enough to keep localized strings updated for every release within a single code tree. Beyond that, you expect that every *client* will update its localized strings for every *server* release? If you agree that is an unrealistic expectation, then even a "highly structured" reporting mechanism won't help. On the other hand, if you truly want to invest the energy required to localize qemu (the server), I can imagine setting the per-client locale as a monitor command. -- Hollis Blanchard IBM Linux Technology Center