From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1Mzpf3-0002d8-Kl for qemu-devel@nongnu.org; Mon, 19 Oct 2009 06:40:21 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1Mzpey-0002bS-QR for qemu-devel@nongnu.org; Mon, 19 Oct 2009 06:40:21 -0400 Received: from [199.232.76.173] (port=46035 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Mzpey-0002bJ-HT for qemu-devel@nongnu.org; Mon, 19 Oct 2009 06:40:16 -0400 Received: from mx1.redhat.com ([209.132.183.28]:27495) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1Mzpey-0004Ek-1A for qemu-devel@nongnu.org; Mon, 19 Oct 2009 06:40:16 -0400 Message-ID: <4ADC4208.4060701@redhat.com> Date: Mon, 19 Oct 2009 12:40:08 +0200 From: Gerd Hoffmann MIME-Version: 1.0 Subject: Re: [Qemu-devel] [PATCH 7/9] qdev: Use QError for not found error References: <1255453026-18637-1-git-send-email-lcapitulino@redhat.com> <1255453026-18637-8-git-send-email-lcapitulino@redhat.com> <877huy6hzm.fsf@pike.pond.sub.org> <20091019101241.GA27871@redhat.com> In-Reply-To: <20091019101241.GA27871@redhat.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: "Daniel P. Berrange" Cc: qemu-devel@nongnu.org, aliguori@us.ibm.com, Markus Armbruster , Luiz Capitulino > I think just returning error codes to the client is far too little > information. I don't think we need the fully normalized structure > that Luiz originally proposed with bus/dev addresses split out, but > we certainly need to include a string description giving as much > detail as possible. If attaching a host USB device failed, I don't > want a single error code QERR_OPEN_FAILED, nor a generic message > like 'could not open device', i want the exact details, eg > > 'could not open device: permission denied' > 'could not open device: no such file or directory' > 'could not open device: device or resource busy' Which makes me wonder whenever it makes sense to re-use errno for the error codes instead of inventing our own QERR_* codes? Not the numbers of course because they are not standardized as far I know, but the Ename strings. If you error out because a system call failed you can pass up errno straight to the client without loosing information along the way. And for other error conditions it should be possible to find error codes describing what happened, i.e. when trying to add a device where no backend driver exists in qemu you can return ENOENT (plus freeform text message for error logging). cheers, Gerd