From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1NughD-0007xM-Hj for qemu-devel@nongnu.org; Thu, 25 Mar 2010 02:37:35 -0400 Received: from [140.186.70.92] (port=57167 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1NughA-0007wt-Sp for qemu-devel@nongnu.org; Thu, 25 Mar 2010 02:37:34 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69) (envelope-from ) id 1Nugh9-0006Fc-6t for qemu-devel@nongnu.org; Thu, 25 Mar 2010 02:37:32 -0400 Received: from mx1.redhat.com ([209.132.183.28]:61609) by eggs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1Nugh8-0006FS-U9 for qemu-devel@nongnu.org; Thu, 25 Mar 2010 02:37:31 -0400 Message-ID: <4BAB0495.8000808@redhat.com> Date: Thu, 25 Mar 2010 08:37:09 +0200 From: Avi Kivity MIME-Version: 1.0 Subject: Re: [Qemu-devel] Re: [libvirt] Supporting hypervisor specific APIs in libvirt References: <4BA7C40C.2040505@codemonkey.ws> <20100323145105.GV16253@redhat.com> <4BA8D8A9.7090308@codemonkey.ws> <201003231557.19474.paul@codesourcery.com> <4BA8E6FC.9080207@codemonkey.ws> <4BA901B5.3020704@redhat.com> <4BA9A066.3070904@redhat.com> <20100324103643.GB624@redhat.com> <4BA9EC88.6000906@redhat.com> <20100324134250.38822113@redhat.com> <4BAA6CD9.6060001@redhat.com> <20100324171219.4365318b@redhat.com> <4BAA76EA.2060601@codemonkey.ws> In-Reply-To: <4BAA76EA.2060601@codemonkey.ws> 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: Anthony Liguori Cc: "libvir-list@redhat.com" , qemu-devel@nongnu.org, Paul Brook , Luiz Capitulino On 03/24/2010 10:32 PM, Anthony Liguori wrote: > > So far, a libqemu.so with a flexible transport that could be used > directly by a libvirt user (ala cairo/gdk type interactions) seems > like the best solution to me. libqemu.so would be a C API. C is not the first choice for writing GUIs or management applications. So it would need to be further wrapped. We also need to allow qemu to control the display directly, without going through vnc. -- Do not meddle in the internals of kernels, for they are subtle and quick to panic.