From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:47231) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Sueez-0006L0-Ht for qemu-devel@nongnu.org; Fri, 27 Jul 2012 03:08:33 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Sueey-0002Ra-CI for qemu-devel@nongnu.org; Fri, 27 Jul 2012 03:08:29 -0400 Received: from mx1.redhat.com ([209.132.183.28]:53097) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Sueey-0002RU-2a for qemu-devel@nongnu.org; Fri, 27 Jul 2012 03:08:28 -0400 From: Markus Armbruster References: <87ipdacrhj.fsf@codemonkey.ws> Date: Fri, 27 Jul 2012 09:08:25 +0200 In-Reply-To: <87ipdacrhj.fsf@codemonkey.ws> (anthony@codemonkey.ws's message of "Thu, 26 Jul 2012 13:22:15 -0500") Message-ID: <87fw8dheae.fsf@blackfin.pond.sub.org> MIME-Version: 1.0 Content-Type: text/plain Subject: Re: [Qemu-devel] Plan for error handling in QMP List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: anthony@codemonkey.ws Cc: Kevin Wolf , Paolo Bonzini , qemu-devel@nongnu.org, Luiz Capitulino anthony@codemonkey.ws writes: > Hi, > > We had a violent^Wheated discussion on IRC about how to move forward > with Luiz's proposed error series. I think we reached consensus. This > note attempts to outline that. > > Principles > ---------- > 1. Errors should be free formed strings with a class code > > 2. There should be a small number of class codes (10-15) added > strictly when there are specific users of a code. > > 3. The class code should be expressed as an enum data type in the normal > QMP schema. Other than this, errors should have no structure in the > schema.[*] > > 4. We should drop all dictionary arguments in the current error > mechanisms beyond 'class' and 'desc'. > > 5. The following errors are used by libvirt: > - CommandNotFound: QMP parsing > - DeviceNotActive/KVMMissingCap: ballooning > - DeviceNotFound: drive_del > - MigrationExpected: cont > > 6. We need to make sure that these errors are preserved while other > errors should be consolidated. > - We need to state very clear for 1.2 which errors are going away. > > 7. We need to make sure that anything we expose in 1.2 stays that way. > If we're dropping 'InvalidParameterType' as a class code, it should be > dropped in 1.2. This could be achieved by making all existing codes > except for those in (5) report 'UnknownError' or something.[*] I'd call it 'Error'. > [*] I took a little bit of license with these. Hopefully it's not > controversial. Forward progress! ACK