From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1NuTfp-0004ES-6C for qemu-devel@nongnu.org; Wed, 24 Mar 2010 12:43:17 -0400 Received: from [140.186.70.92] (port=56711 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1NuTfl-0004EK-E3 for qemu-devel@nongnu.org; Wed, 24 Mar 2010 12:43:16 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69) (envelope-from ) id 1NuTfi-0004cM-LH for qemu-devel@nongnu.org; Wed, 24 Mar 2010 12:43:13 -0400 Received: from mx1.redhat.com ([209.132.183.28]:38888) by eggs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1NuTfi-0004bu-Dx for qemu-devel@nongnu.org; Wed, 24 Mar 2010 12:43:10 -0400 Date: Wed, 24 Mar 2010 13:42:50 -0300 From: Luiz Capitulino Subject: Re: [Qemu-devel] Re: [libvirt] Supporting hypervisor specific APIs in libvirt Message-ID: <20100324134250.38822113@redhat.com> In-Reply-To: <4BA9EC88.6000906@redhat.com> 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> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Avi Kivity Cc: "libvir-list@redhat.com" , Paul Brook , qemu-devel@nongnu.org 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? I don't see how adding yet another layer/daemon is going to improve ours and user's life (the same applies for libqemu). 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?