From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1MJUqn-0000c3-BT for qemu-devel@nongnu.org; Wed, 24 Jun 2009 11:57:29 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1MJUqj-0000YD-92 for qemu-devel@nongnu.org; Wed, 24 Jun 2009 11:57:28 -0400 Received: from [199.232.76.173] (port=38746 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1MJUqh-0000Xm-RS for qemu-devel@nongnu.org; Wed, 24 Jun 2009 11:57:24 -0400 Received: from mail-ew0-f211.google.com ([209.85.219.211]:58062) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1MJUqh-0001EZ-88 for qemu-devel@nongnu.org; Wed, 24 Jun 2009 11:57:23 -0400 Received: by ewy7 with SMTP id 7so1226799ewy.34 for ; Wed, 24 Jun 2009 08:57:22 -0700 (PDT) MIME-Version: 1.0 In-Reply-To: <4A42200C.6060600@codemonkey.ws> References: <4A40FB11.8090100@redhat.com> <4A40FE31.2010007@us.ibm.com> <4A40FFB0.2070905@redhat.com> <4A411FC5.7050701@us.ibm.com> <4A412339.5000109@redhat.com> <4A412659.1080803@us.ibm.com> <20090623220204.GA5612@snarc.org> <4A415C30.7030301@us.ibm.com> <20090624010108.GA6537@snarc.org> <4A42200C.6060600@codemonkey.ws> Date: Wed, 24 Jun 2009 17:57:22 +0200 Message-ID: <5b31733c0906240857g546316e0pd92fee9afe6115fa@mail.gmail.com> Subject: Re: [Qemu-devel] [PATCH 01/11] QMP: Introduce specification file From: Filip Navara Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Anthony Liguori Cc: ehabkost@redhat.com, jan.kiszka@siemens.com, dlaor@redhat.com, qemu-devel@nongnu.org, Luiz Capitulino , Avi Kivity , Vincent Hanquez On Wed, Jun 24, 2009 at 2:46 PM, Anthony Liguori wro= te: [snip] > With respect to RPC choice, if we did go that route, I'd be very concerne= d > about using jsonrpc verses a more well established rpc. =A0I would honest= ly > prefer xml-rpc over jsonrpc. > > One reason to choose an RPC is based on the adoption of it. =A0You want t= o use > something that has a vibrant community with well established client > libraries to make writing clients as easy as possible. =A0Without an acti= ve > jsonrpc C library, it's hard to argue that jsonrpc has that. =A0xml-rpc > certainly does. After reading the XDR specification I realized that the basic blocks are already implemented in QEMU. Data type mapping: Integer <-> qemu_put_sbe32 / qemu_get_sbe32 Unsigned Integer <-> qemu_put_be32 / qemu_get_be32 Enumeration - same as signed integer Boolean - same as signed interger, limited to values 0 and 1 Hyper Integer <-> qemu_put_sbe64 / qemu_get_sbe64 Unsigned Hyper Integer <-> qemu_put_be64 / qemu_get_be64 Floating-point, Double-precision Floating-point, Quadruple-precision Floating-point <-> ? (uses IEEE notation) Fixed-length Opaque Data <-> void qemu_put_xdr_buffer(QEMUFile *f, const uint8_t *buf, int size) { int reminder =3D size % 4; qemu_put_buffer(f, buf, size); while (--reminder >=3D 0) qemu_put_byte(f, 0); } Variable-length Opaque Data <-> void qemu_put_xdr_var_buffer(QEMUFile *f, const uint8_t *buf, int size) { int reminder =3D size % 4; qemu_put_be32(f, size); qemu_put_buffer(f, buf, size); while (--reminder >=3D 0) qemu_put_byte(f, 0); } String <-> same as qemu_put_xdr_var_buffer, ASCII bytes (*not characters*, the encoding of characters is not part of the RFC, NFSv4 uses UTF-8 for example), null-terminator is not sent Fixed-length Array <-> for loop with the elements described using the basic types above Variable-length Array <-> qemu_put_be32 + for loop / qemu_get_be32 + allocation + for loop Structure, Discriminated Union <-> built from the basic data types, same as= in C Void <-> nothing :) Given the fact that we practically have the library for XDR it would be very easy to build Sun RPC server on top of it. So my vote is for SunRPC. Best regards, Filip Navara