From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from [140.186.70.92] (port=56824 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1ON42x-0003pc-19 for qemu-devel@nongnu.org; Fri, 11 Jun 2010 09:14:05 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69) (envelope-from ) id 1ON42P-0005eu-B5 for qemu-devel@nongnu.org; Fri, 11 Jun 2010 09:12:46 -0400 Received: from mx1.redhat.com ([209.132.183.28]:48874) by eggs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1ON42P-0005eg-4R for qemu-devel@nongnu.org; Fri, 11 Jun 2010 09:12:45 -0400 Received: from int-mx08.intmail.prod.int.phx2.redhat.com (int-mx08.intmail.prod.int.phx2.redhat.com [10.5.11.21]) by mx1.redhat.com (8.13.8/8.13.8) with ESMTP id o5BDCiA8001955 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Fri, 11 Jun 2010 09:12:44 -0400 Date: Fri, 11 Jun 2010 10:12:40 -0300 From: Luiz Capitulino Message-ID: <20100611101240.4b88d660@redhat.com> In-Reply-To: References: <71b2d15bfd8bdcff2561e5597de79ccb136177c0.1276085283.git.quintela@redhat.com> <20100609175446.7296bee3@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Subject: [Qemu-devel] Re: [PATCH v3 3/5] QMP: Introduce MIGRATION events List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Juan Quintela Cc: qemu-devel@nongnu.org On Thu, 10 Jun 2010 12:33:42 +0200 Juan Quintela wrote: > Luiz Capitulino wrote: > > On Wed, 9 Jun 2010 14:10:56 +0200 > > Juan Quintela wrote: > > >> +MIGRATION_FAILED > >> +---------------- > >> + > >> +Emitted when migration fails (both is source and target). Notice > >> +that this event will be changed for 0.14 when we have infrastructure > >> +to emit a QError when things fail. > > > > This is not the kind of information this file should have, compatible > > changes should be noted when time comes and incompatible ones are just > > forbidden after 0.13. > > Then how you express that this value is going to have a QError in it on > the future? We don't have to, the doc's purpose is to describe the current state of the protocol. There might be exceptions, but in this case the change is compatible and extending the protocol is something that is going to happen at every release. The doc will be updated when the change is introduced. > Adding a Default QError that puts 'This QError is going to be refined' > or what? We only have to do something like that if having the error information is something needed right now, which is the case of the BLOCK_IO_ERROR event.