From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1NunxZ-0005jw-EQ for qemu-devel@nongnu.org; Thu, 25 Mar 2010 10:22:57 -0400 Received: from [140.186.70.92] (port=50032 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1NunxX-0005jS-SF for qemu-devel@nongnu.org; Thu, 25 Mar 2010 10:22:57 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69) (envelope-from ) id 1NunxW-0006rR-7o for qemu-devel@nongnu.org; Thu, 25 Mar 2010 10:22:55 -0400 Received: from cerberus.snarc.org ([212.85.155.21]:59336) by eggs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1NunxW-0006rN-2n for qemu-devel@nongnu.org; Thu, 25 Mar 2010 10:22:54 -0400 Date: Thu, 25 Mar 2010 14:22:51 +0000 From: Vincent Hanquez Subject: Re: [Qemu-devel] Re: [libvirt] Supporting hypervisor specific APIs in libvirt Message-ID: <20100325142251.GA25270@snarc.org> References: <20100324171219.4365318b@redhat.com> <4BAA76EA.2060601@codemonkey.ws> <20100324182501.000b69a7@redhat.com> <4BAA86C2.4020701@codemonkey.ws> <4BAB1E21.8080009@snarc.org> <4BAB5805.9080000@codemonkey.ws> <4BAB58F1.20401@redhat.com> <4BAB68A2.6020707@codemonkey.ws> <4BAB69C9.6080704@redhat.com> <4BAB6BD0.1000509@codemonkey.ws> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4BAB6BD0.1000509@codemonkey.ws> List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Anthony Liguori Cc: "libvir-list@redhat.com" , Paul Brook , Luiz Capitulino , Avi Kivity , qemu-devel@nongnu.org On Thu, Mar 25, 2010 at 08:57:36AM -0500, Anthony Liguori wrote: > Why? > > We can provide a generic QMP dispatch interface that high level > languages can use. Then they can do fancy dispatch, treat QErrors as > exceptions, etc. Because more than likely it will be more efforts than doing the same work in the native language, forcing certains designs [1] up to high-level-language developers throats, and possibly less stability (segfault, memory corruption, memory leak, ..) specially in development phase. [1] lack of separation between IO and pure functions, file descriptor versus stream, C memory functions instead of GC based, and probably lots of other things easily accessible from high level language. -- Vincent