From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:52890) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SuShZ-0003JG-Sl for qemu-devel@nongnu.org; Thu, 26 Jul 2012 14:22:22 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1SuShY-0008VR-Np for qemu-devel@nongnu.org; Thu, 26 Jul 2012 14:22:21 -0400 Received: from mail-pb0-f45.google.com ([209.85.160.45]:34340) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SuShY-00086V-IN for qemu-devel@nongnu.org; Thu, 26 Jul 2012 14:22:20 -0400 Received: by mail-pb0-f45.google.com with SMTP id ro12so3475448pbb.4 for ; Thu, 26 Jul 2012 11:22:20 -0700 (PDT) From: anthony@codemonkey.ws Date: Thu, 26 Jul 2012 13:22:15 -0500 Message-ID: <87ipdacrhj.fsf@codemonkey.ws> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Subject: [Qemu-devel] Plan for error handling in QMP List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: qemu-devel@nongnu.org Cc: Kevin Wolf , Paolo Bonzini , Markus Armbruster , Luiz Capitulino 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 took a little bit of license with these. Hopefully it's not controversial. Regards, Anthony Liguori