From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from [140.186.70.92] (port=45492 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1PhW1S-0001MI-1L for qemu-devel@nongnu.org; Mon, 24 Jan 2011 18:40:35 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1PhW1Q-0002MA-J8 for qemu-devel@nongnu.org; Mon, 24 Jan 2011 18:40:33 -0500 Received: from e37.co.us.ibm.com ([32.97.110.158]:44334) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1PhW1Q-0002Lh-Dp for qemu-devel@nongnu.org; Mon, 24 Jan 2011 18:40:32 -0500 Received: from d03relay03.boulder.ibm.com (d03relay03.boulder.ibm.com [9.17.195.228]) by e37.co.us.ibm.com (8.14.4/8.13.1) with ESMTP id p0ONbqB5013314 for ; Mon, 24 Jan 2011 16:37:52 -0700 Received: from d03av03.boulder.ibm.com (d03av03.boulder.ibm.com [9.17.195.169]) by d03relay03.boulder.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id p0ONeL9r098110 for ; Mon, 24 Jan 2011 16:40:21 -0700 Received: from d03av03.boulder.ibm.com (loopback [127.0.0.1]) by d03av03.boulder.ibm.com (8.14.4/8.13.1/NCO v10.0 AVout) with ESMTP id p0ONeKPY009550 for ; Mon, 24 Jan 2011 16:40:21 -0700 Message-ID: <4D3E0DD5.8070408@linux.vnet.ibm.com> Date: Mon, 24 Jan 2011 17:40:05 -0600 From: Anthony Liguori MIME-Version: 1.0 Subject: Re: [Qemu-devel] Re: [RFC][PATCH v6 08/23] virtagent: add va.getfile RPC References: <1295270117-24760-1-git-send-email-mdroth@linux.vnet.ibm.com> <1295270117-24760-9-git-send-email-mdroth@linux.vnet.ibm.com> <4D39B716.1010400@redhat.com> <20110121172026.GK12589@redhat.com> <4D39CF2C.1000407@linux.vnet.ibm.com> <20110124220809.GA4254@amd.home.annexia.org> <20110124222019.GA4602@amd.home.annexia.org> <4D3DFC81.4010807@linux.vnet.ibm.com> <20110124224808.GF25174@amd.home.annexia.org> In-Reply-To: <20110124224808.GF25174@amd.home.annexia.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: "Richard W.M. Jones" Cc: agl@linux.vnet.ibm.com, stefanha@linux.vnet.ibm.com, Jes Sorensen , marcel.mittelstaedt@de.ibm.com, qemu-devel@nongnu.org, Michael Roth , ryanh@us.ibm.com, markus_mueller@de.ibm.com, abeekhof@redhat.com On 01/24/2011 04:48 PM, Richard W.M. Jones wrote: > On Mon, Jan 24, 2011 at 04:26:09PM -0600, Anthony Liguori wrote: > >> On 01/24/2011 04:20 PM, Richard W.M. Jones wrote: >> >>> On Mon, Jan 24, 2011 at 10:08:09PM +0000, Richard W.M. Jones wrote: >>> >>>> You might as well reuse the libguestfs API here because you get the >>>> benefit of all the code that's been written, all the tools on top, and >>>> a far more comprehensive API that would take you another 2 years to >>>> implement. >>>> >>> To put it in some perspective, libguestfs is just shy of 500K lines of >>> code now, not including the tools built on top. 150 page manual just >>> for the core API. >>> >> Yeah, but I think that's the reason that it might not be a good >> candidate for this use-case. >> >> We need a *simple* interface that we can convince everyone to >> install by default and run in their guests. It needs to be flexible >> enough that we can do lots of fun things but simple enough that a >> reasonable person can audit the code in a short period of time. >> >> It will never replace something as sophisticated as guestfs but >> that's not it's point. It's point is to let you do simple things >> like execute a command in the guest or peek at /proc/meminfo. You >> don't need 500k LOCs for that. >> > I don't really want to argue over this, since I think accessing live > VMs like this is a really useful feature, and it complements > libguestfs (image editing) very nicely. > > I'll just say that you might not think you need it to start off with > (and we didn't either), but when you notice that "simple" > open/read/write/close Oh I don't think there should be an open/read/write/close interface. I'm quite happy with the current copyfile interface. > in fact has terrible performance so you need to > specialize many operations, and then someone wants to create a > filesystem, and someone else wants a FUSE interface, suddenly you'll > be reimplementing large parts of libguestfs. > Nope. If you want to do fancy things, use libguestfs :-) BTW, how dependent is guestfsd on the guest that libguestfs uses? I wasn't even aware that it could be used outside of that context. Regards, Anthony Liguori > The daemon (guestfsd) is 36106 LoC. > > Rich. > >