From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1NvByd-000142-F7 for qemu-devel@nongnu.org; Fri, 26 Mar 2010 12:01:39 -0400 Received: from [140.186.70.92] (port=42291 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1NvByZ-000134-1K for qemu-devel@nongnu.org; Fri, 26 Mar 2010 12:01:39 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69) (envelope-from ) id 1NvByW-00067i-MF for qemu-devel@nongnu.org; Fri, 26 Mar 2010 12:01:34 -0400 Received: from mx1.redhat.com ([209.132.183.28]:22259) by eggs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1NvByW-00067S-E0 for qemu-devel@nongnu.org; Fri, 26 Mar 2010 12:01:32 -0400 Message-ID: <4BACDA46.4030403@redhat.com> Date: Fri, 26 Mar 2010 19:01:10 +0300 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> <4BAB0495.8000808@redhat.com> <237B6CC7-857E-4C2C-889A-ABED1D747FCC@suse.de> In-Reply-To: <237B6CC7-857E-4C2C-889A-ABED1D747FCC@suse.de> 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: Alexander Graf Cc: "libvir-list@redhat.com" , Paul Brook , qemu-devel@nongnu.org, Luiz Capitulino On 03/25/2010 10:18 AM, Alexander Graf wrote: > >> 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. >> > For the current functionality I tend to disagree. All that we need is an shm vnc extension that allows the GUI and qemu to not send image data over the wire, but only the dirtyness information. > It still means an extra copy. I don't think we want to share the guest framebuffer (it includes offscreen bitmaps), so we'll need to copy it somewhere else. It's even worse with qxl/spice where there is no framebuffer. > As soon as we get to 3D things might start to look different. > Very different. -- Do not meddle in the internals of kernels, for they are subtle and quick to panic.