From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1MK7Y0-0001GT-L5 for qemu-devel@nongnu.org; Fri, 26 Jun 2009 05:16:40 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1MK7Xv-0001C3-M6 for qemu-devel@nongnu.org; Fri, 26 Jun 2009 05:16:40 -0400 Received: from [199.232.76.173] (port=41629 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1MK7Xv-0001Br-F7 for qemu-devel@nongnu.org; Fri, 26 Jun 2009 05:16:35 -0400 Received: from mx2.redhat.com ([66.187.237.31]:51802) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1MK7Xu-0002Mn-Nl for qemu-devel@nongnu.org; Fri, 26 Jun 2009 05:16:35 -0400 Message-ID: <4A4491F6.8020502@redhat.com> Date: Fri, 26 Jun 2009 12:16:38 +0300 From: Avi Kivity MIME-Version: 1.0 Subject: Re: [Qemu-devel] [PATCH 01/11] QMP: Introduce specification file References: <5b31733c0906241224j50baa7e6lc80b8c79c5d6baa7@mail.gmail.com> <20090624211358.GA14121@shareable.org> <4A43768A.2090604@eu.citrix.com> <4A438FDD.5060206@redhat.com> <4A43935D.6000506@codemonkey.ws> <4A4395B8.4010401@redhat.com> <4A43AE13.4030900@eu.citrix.com> <4A43BD9C.8070304@codemonkey.ws> <20090625190302.GA11937@redhat.com> <4A448E46.1000707@redhat.com> <20090626091012.GD28206@redhat.com> In-Reply-To: <20090626091012.GD28206@redhat.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: "Daniel P. Berrange" Cc: "ehabkost@redhat.com" , Stefano Stabellini , "jan.kiszka@siemens.com" , "dlaor@redhat.com" , "qemu-devel@nongnu.org" , Luiz Capitulino , Filip Navara , Vincent Hanquez On 06/26/2009 12:10 PM, Daniel P. Berrange wrote: > >> Let's turn this around. IIRC libvirt uses an RPC interface for its >> clients. How would you estimate the effort to port this interface to >> QMP, and adapt all its clients? >> > > The libvirt RPC interface is a binary message based protocol, using XDR > to encode arguments/return values, and emit signals. The libvirt for > handling this is quite complex because it has to deal with TLS, and > SASL for data encryption, as well as alllowing overlapping RPC requests > on a single TCP connection ( to allow multi-threaded clients to have > parallelized method calls without opening multiple connections). So > it would be a fairly significant amount of work, in comparison to the > current QMP proposal. > You're describing an RPC with asynchronous commands and notifications, with support for authentication and authorization. While qemu doesn't need auth*, it does need the other features, so RPC looks like a good fit. > The existing libvirt code to talk to QEMU's monitor is actually rather > simple by comparison to our native RPC code. The problems we have > historically had with the QEMU monitor were, ill defined data printed > when an error occurs, the changing of monitor commands between QEMU > releases in incompatible ways, the lack of quoting for arguments and > no support for async events. > No doubt RPC is complicated if you implement it yourself, but surely you used a library? Actually using the RPC is simpler than a line protocol. -- I have a truly marvellous patch that fixes the bug which this signature is too narrow to contain.