From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:48158) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SfZmM-0008VY-Fk for qemu-devel@nongnu.org; Fri, 15 Jun 2012 12:53:47 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1SfZmK-0004MR-Ku for qemu-devel@nongnu.org; Fri, 15 Jun 2012 12:53:46 -0400 Received: from e8.ny.us.ibm.com ([32.97.182.138]:52629) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SfZmK-00046N-H4 for qemu-devel@nongnu.org; Fri, 15 Jun 2012 12:53:44 -0400 Received: from /spool/local by e8.ny.us.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Fri, 15 Jun 2012 12:53:04 -0400 Received: from d01relay04.pok.ibm.com (d01relay04.pok.ibm.com [9.56.227.236]) by d01dlp01.pok.ibm.com (Postfix) with ESMTP id 4A17A38C8056 for ; Fri, 15 Jun 2012 12:53:00 -0400 (EDT) Received: from d03av02.boulder.ibm.com (d03av02.boulder.ibm.com [9.17.195.168]) by d01relay04.pok.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id q5FGqwu5205278 for ; Fri, 15 Jun 2012 12:52:59 -0400 Received: from d03av02.boulder.ibm.com (loopback [127.0.0.1]) by d03av02.boulder.ibm.com (8.14.4/8.13.1/NCO v10.0 AVout) with ESMTP id q5FGqw71002642 for ; Fri, 15 Jun 2012 10:52:58 -0600 Message-ID: <4FDB6869.1000509@us.ibm.com> Date: Fri, 15 Jun 2012 11:52:57 -0500 From: Anthony Liguori MIME-Version: 1.0 References: <1338387301-10074-1-git-send-email-lcapitulino@redhat.com> <1338387301-10074-3-git-send-email-lcapitulino@redhat.com> <4FC74B1A.8080700@redhat.com> <20120531110608.4dc3fe22@doriath.home> <4FC77F6C.8000008@redhat.com> <20120531113127.1c8aa213@doriath.home> <4FC78637.4040605@redhat.com> <20120613144910.598bfe24@doriath.home> In-Reply-To: <20120613144910.598bfe24@doriath.home> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] Adding errno to QMP errors List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Luiz Capitulino Cc: Kevin Wolf , Paolo Bonzini , qemu-devel@nongnu.org, armbru@redhat.com On 06/13/2012 12:49 PM, Luiz Capitulino wrote: > On Thu, 31 May 2012 16:54:47 +0200 > Paolo Bonzini wrote: > >> Wait, I think you're conflating two things. >> >> One is "do not shoehorn errors into errno values". So for QOM invalid values we >> have PropertyValueBad, not a generic InvalidArgument value. We convert everything >> to Error rather than returning negative errno values and then returning generic >> error codes, because those would be ugly and non-descriptive. I agree with that. >> >> The other is "when errors come straight from the OS, _do_ use errno values". >> This is for OpenFileFailed, for the new socket errors and so on. This is what >> I am proposing. > > [...] > >> $ echo | sed p> /dev/full >> sed: couldn't flush stdout: No space left on device >> ^^^^^^^^^^^^^^ error type >> ^^^^^^ ^^^^^^^^^^^^^^^^^^^^^^^ arguments >> >> That would become, in JSON: >> >> { 'error': 'FlushFailed', >> 'file': 'stdout', >> 'os_error': 'enospc' } > > This is not a new discussion and what we're doing today is to return errno > as a QError class name. So, for the example above we'd return something like: > > { 'error': 'NoSpace' } No, you're confusing things I think. { 'error': 'NoSpace' } is bad. errno is not an intrinsically bad thing but errno critically relies on the *caller* to understand the context that the error has occurred in. Just returning { 'error': 'NoSpace' } is not good enough in QMP because the caller doesn't know the context. What was the command doing such that that error was returning? In many cases, errno has different meanings depending on the context. EINVAL is a good example of this. The devil is in the details here. Having an error like: { 'error': 'OpenFileFailed', 'file': 'filename', 'mode': 'r/w', 'os_error': 'enospc' } is actually pretty reasonable for something like a memory dump command where the user specifies a file. OTOH, for something complex like live snapshotting which many involve opening multiple files, it may not be good enough. So context is really everything here. Regards, Anthony Liguori > > It's possible to add new optional values if you need more information, but > I know that that's not what you're asking. > > I mostly agree that your version would be better, the only problem I see > is that this is probably going to mess a bit more our API as we have been > doing like my example above for some time. > > Anthony, the current design was mostly influenced by you and you had > objections on doing what Paolo and Kevin are suggesting. What do you think? >