From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1Mu1jW-0000lz-EX for qemu-devel@nongnu.org; Sat, 03 Oct 2009 06:20:58 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1Mu1jR-0000lU-Gb for qemu-devel@nongnu.org; Sat, 03 Oct 2009 06:20:57 -0400 Received: from [199.232.76.173] (port=33023 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Mu1jR-0000lN-AL for qemu-devel@nongnu.org; Sat, 03 Oct 2009 06:20:53 -0400 Received: from mx1.redhat.com ([209.132.183.28]:44433) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1Mu1jQ-0005rF-R8 for qemu-devel@nongnu.org; Sat, 03 Oct 2009 06:20:53 -0400 Message-ID: <4AC721C9.5030006@redhat.com> Date: Sat, 03 Oct 2009 12:04:57 +0200 From: Avi Kivity MIME-Version: 1.0 Subject: Re: [Qemu-devel] Release plan for 0.12.0 References: <4AC29E4D.80707@us.ibm.com> <4AC2FD93.80208@redhat.com> <4AC3578C.8070105@us.ibm.com> <20091001181338.0007a1fc@doriath> In-Reply-To: <20091001181338.0007a1fc@doriath> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Luiz Capitulino Cc: Anthony Liguori , "qemu-devel@nongnu.org" , kvm-devel , Paul Brook On 10/01/2009 11:13 PM, Luiz Capitulino wrote: >> If we're going to support the protocol for 0.12, I'd like to most of the >> code merged by the end of October. >> > Four weeks.. Not so much time, but let's try. > > There are two major issues that may delay QMP. > > Firstly, we are still on the infrastructure/design phase, which > is natural to take time. Maybe when handlers start getting converted > en masse things will be faster. > I sure hope so. Maybe someone can pitch in if not. > Secondly: testing. I have a very ugly python script to test the > already converted handlers. The problem is not only the ugliness, > the right way to do this would be to use kvm-autotest. So, I was > planning to take a detailed look at it and perhaps start writing > tests for QMP right when each handler is converted. Right Thing, > but takes time. > I think this could be done by having autotest use two monitors, one with the machine protocol and one with the human protocol, trying first the machine protocol and falling back if the command is not supported. Hopefully we can get the autotest people to work on it so we parallelize development. They'll also give user-oriented feedback which can be valuable. Are you using a standard json parser with your test script? That's an additional validation. -- Do not meddle in the internals of kernels, for they are subtle and quick to panic.