From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1NV7Fu-0000Ji-Kc for qemu-devel@nongnu.org; Wed, 13 Jan 2010 12:43:42 -0500 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1NV7Fp-0000JK-3s for qemu-devel@nongnu.org; Wed, 13 Jan 2010 12:43:41 -0500 Received: from [199.232.76.173] (port=52925 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1NV7Fo-0000JH-VD for qemu-devel@nongnu.org; Wed, 13 Jan 2010 12:43:36 -0500 Received: from mx1.redhat.com ([209.132.183.28]:58888) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1NV7Fo-0008H9-CU for qemu-devel@nongnu.org; Wed, 13 Jan 2010 12:43:36 -0500 Date: Wed, 13 Jan 2010 15:43:27 -0200 From: Luiz Capitulino Subject: Re: [Qemu-devel] QMP forward compatibility support Message-ID: <20100113154327.5c3d245c@doriath> In-Reply-To: References: <20100111163422.0d86d2bb@doriath> <4B4B748B.6010008@codemonkey.ws> <20100111220436.14c662a5@doriath> <4B4BC138.1000500@codemonkey.ws> <20100112101102.396b15fb@doriath> <20100113150643.24509d01@doriath> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Markus Armbruster Cc: aliguori@us.ibm.com, dlaor@redhat.com, qemu-devel@nongnu.org, avi@redhat.com On Wed, 13 Jan 2010 18:38:57 +0100 Markus Armbruster wrote: > Luiz Capitulino writes: > > > On Wed, 13 Jan 2010 17:53:38 +0100 > > Markus Armbruster wrote: > > > >> Luiz Capitulino writes: > [...] > >> > I'm thinking in something like this: > >> > > >> > 1. Connection is made, the greeting message is sent and QMP is > >> > in 'handshake mode' > >> > > >> > 2. In this mode only commands to enable/disable protocol > >> > capabilities are allowed > >> > > >> > 3. When the client is done with the setup, it issues the > >> > command 'enable-qmp', which puts the protocol into 'running mode', > >> > where any command is accepted > >> > >> Really "any command"? What about commands to enable/disable protocol > >> capabilities? > > > > I think that playing with some protocol bits might be safe, like > > enabling async messages. > > > > I'm not saying this is a good practice, but forbidding it seems a bit > > extreme at first. > > Allowing stuff when it turns out to be needed is less painful than > outlawing stuff when it turns out to be problematic. I forgot to mention we can block them, that's fine. :) So, do we agree with the general design? I'll cook a RFC series.