From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1NuWcB-0003a3-Aq for qemu-devel@nongnu.org; Wed, 24 Mar 2010 15:51:43 -0400 Received: from [140.186.70.92] (port=54381 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1NuWc9-0003ZH-Nq for qemu-devel@nongnu.org; Wed, 24 Mar 2010 15:51:42 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69) (envelope-from ) id 1NuWab-000288-SZ for qemu-devel@nongnu.org; Wed, 24 Mar 2010 15:50:08 -0400 Received: from mx1.redhat.com ([209.132.183.28]:11079) by eggs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1NuWab-00027n-KU for qemu-devel@nongnu.org; Wed, 24 Mar 2010 15:50:05 -0400 Message-ID: <4BAA6CD9.6060001@redhat.com> Date: Wed, 24 Mar 2010 21:49:45 +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> In-Reply-To: <20100324134250.38822113@redhat.com> 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: Luiz Capitulino Cc: "libvir-list@redhat.com" , Paul Brook , qemu-devel@nongnu.org On 03/24/2010 06:42 PM, Luiz Capitulino wrote: > On Wed, 24 Mar 2010 12:42:16 +0200 > Avi Kivity wrote: > > >> So, at best qemud is a toy for people who are annoyed by libvirt. >> > Is the reason for doing this in qemu because libvirt is annoying? Mostly. > I don't see > how adding yet another layer/daemon is going to improve ours and user's life > (the same applies for libqemu). > libvirt becomes optional. > If I got it right, there were two complaints from the kvm-devel flamewar: > > 1. Qemu has usability problems > 2. There's no way an external tool can get /proc/kallsyms info from Qemu > > I don't see how libqemu can help with 1) and having qemud doesn't seem > the best solution for 2) either. > > Still talking about 2), what's wrong in getting the PID or having a QMP > connection in a well known location as suggested by Anthony? > I now believe that's the best option. -- Do not meddle in the internals of kernels, for they are subtle and quick to panic.