From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:56806) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VHCsf-0004hr-VB for qemu-devel@nongnu.org; Wed, 04 Sep 2013 09:12:26 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1VHCsb-0002P8-3U for qemu-devel@nongnu.org; Wed, 04 Sep 2013 09:12:21 -0400 Received: from mx1.redhat.com ([209.132.183.28]:63017) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VHCsa-0002Or-S2 for qemu-devel@nongnu.org; Wed, 04 Sep 2013 09:12:17 -0400 Date: Wed, 4 Sep 2013 09:12:02 -0400 From: Luiz Capitulino Message-ID: <20130904091202.1b852e6e@redhat.com> In-Reply-To: <52272FD1.5030906@suse.de> References: <1375366359-11553-1-git-send-email-jjherne@us.ibm.com> <52272B78.3010804@suse.de> <20130904085647.03532941@redhat.com> <52272FD1.5030906@suse.de> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Subject: Re: [Qemu-devel] [PATCH 0/8] [PATCH RFC v3] s390 cpu hotplug List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Andreas =?UTF-8?B?RsOkcmJlcg==?= Cc: agraf@suse.de, ehabkost@redhat.com, qemu-devel@nongnu.org, "Jason J. Herne" , borntraeger@de.ibm.com, jfrei@linux.vnet.ibm.com, imammedo@redhat.com On Wed, 04 Sep 2013 15:04:17 +0200 Andreas F=C3=A4rber wrote: > Am 04.09.2013 14:56, schrieb Luiz Capitulino: > > On Wed, 04 Sep 2013 14:45:44 +0200 > > Andreas F=C3=A4rber wrote: > >=20 > >> For the HMP patch I am waiting on feedback from Igor once he returns > >> from his vacation and, if there are no objections, would like to see > >> that patch go through Luiz' queue since unrelated to s390x. > >=20 > > I don't remember seeing that patch, I was CC'ed? It should be good then :) >=20 > Originally no, but you added a Reviewed-by after I CC'ed you. :) >=20 > Apart from me not being familiar with the HMP infrastructure, I was > wondering if there was a reason why this wasn't done from the start. >=20 > So we don't have some only-new-QMP-commands policy Not sure what you meant, but what is usually not accepted are new HMP-only commands. > and people are > encouraged to implement an HMP command when they do a QMP command? If the new command makes sense in HMP, yes they're.