From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:60521) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SuT20-00054x-TK for qemu-devel@nongnu.org; Thu, 26 Jul 2012 14:43:29 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1SuT1v-0007kR-0M for qemu-devel@nongnu.org; Thu, 26 Jul 2012 14:43:28 -0400 Received: from mx1.redhat.com ([209.132.183.28]:61929) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SuT1u-0007k4-MK for qemu-devel@nongnu.org; Thu, 26 Jul 2012 14:43:22 -0400 Date: Thu, 26 Jul 2012 15:43:58 -0300 From: Luiz Capitulino Message-ID: <20120726154358.69eee026@doriath.home> In-Reply-To: <87ipdacrhj.fsf@codemonkey.ws> References: <87ipdacrhj.fsf@codemonkey.ws> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit 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, Markus Armbruster On Thu, 26 Jul 2012 13:22:15 -0500 anthony@codemonkey.ws wrote: > > 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. This looks great to me, violent^W heated discussions can be so productive :) > > 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 took a little bit of license with these. Hopefully it's not > controversial. > > Regards, > > Anthony Liguori > >