From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1Mzplj-0004YD-T1 for qemu-devel@nongnu.org; Mon, 19 Oct 2009 06:47:15 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1Mzplf-0004Xh-GZ for qemu-devel@nongnu.org; Mon, 19 Oct 2009 06:47:15 -0400 Received: from [199.232.76.173] (port=59866 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Mzplf-0004Xe-Bq for qemu-devel@nongnu.org; Mon, 19 Oct 2009 06:47:11 -0400 Received: from mx1.redhat.com ([209.132.183.28]:19102) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1Mzple-0005Ln-L1 for qemu-devel@nongnu.org; Mon, 19 Oct 2009 06:47:11 -0400 Date: Mon, 19 Oct 2009 11:47:07 +0100 From: "Daniel P. Berrange" Subject: Re: [Qemu-devel] [PATCH 7/9] qdev: Use QError for not found error Message-ID: <20091019104707.GD27871@redhat.com> 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> <4ADC4208.4060701@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4ADC4208.4060701@redhat.com> Reply-To: "Daniel P. Berrange" List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Gerd Hoffmann Cc: qemu-devel@nongnu.org, aliguori@us.ibm.com, Markus Armbruster , Luiz Capitulino On Mon, Oct 19, 2009 at 12:40:08PM +0200, Gerd Hoffmann wrote: > >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). If applicable to the context, I think it is worthwhile including more than just the generic errno string. eg, if failed opening a disk file, then it would be fine to just send back the errno string, because the original drive_add command would already include the filename in question. If failed opening some random sysfs file relating to a PCI device that is being attached, then QEMU should back the sysfs filename because it may not be obvious from just the PCI bus/domain/slot number in the original command just which file QEMU failed to open. Daniel -- |: Red Hat, Engineering, London -o- http://people.redhat.com/berrange/ :| |: http://libvirt.org -o- http://virt-manager.org -o- http://ovirt.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: GnuPG: 7D3B9505 -o- F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :|